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FOREWORD 


This  final  report  of  the  IUS/Tug  Orbital  Operations  and  Mission  Study  was 
prepared  for  the  National  Aeronautics  and  Space  Administration,  George  C 
Marshall  Space  Flight  Center  by  the  IBM  Corporation  in  accordance  with  Contract 
NAS8-31009 


The  study  effort  described  herein  was  conducted  under  the  direction  of  NASA 
Contract  Officer's  Representative  (COR),  Mr.  Sidney  P Saucier  This  report 
was  prepared  by  the  IBM  Corporation,  Federal  Systems  Division,  Huntsville, 
Alabama,  under  the  direction  of  Mr  Roy  E Day,  IBM  Study  Manager.  Technical 
support  was  provided  to  IBM  by  the  Phil  co-Ford  Corporation,  Western  Development 
Laboratories  Division,  Palo  Alto,  California,  under  the  direction  of  Dr 
W E Waters,  Phil  co-Ford  Study  Manager  The  study  results  were  developed 
during  the  period  from  June,  1974,  through  February,  1975,  with  the  final 
report  being  distributed  in  May,  1975 

The  results  of  this  study  have  been  documented  in  five  separate  volumes 


Volume  I 
Volume  II 
Volume  III 
Volume  IV 
Volume  V 


Executive  Summary 
IUS  Operations 
Tug  Operations 
Project  Planning  Data 
Cost  Estimates 


Questions  and  comments  regarding  this  study  activity  should  be  directed  to 

Sidney  P Saucier,  COR 
NASA  Marshall  Space  Flight  Center 
Attention  PF-02-E 
Huntsville,  Alabama  35812 
Telephone  (205)  4532795 

R E Day,  Study  Manager 

International  Business  Machines  Corporation 
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Telephone  (205)  837-4000,  extension  2636 
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INTRODUCTION 


This  volume  contains  the  background  data  and  study  results  for  the  Space  Tug 
portion  of  the  IUS/Tug  Orbital  Operations  and  Mission  Support  Study  For  the 
purpose  of  this  final  report  the  contract  name  has  been  shortened  to  "Orbital 
Operations  Study"  This  volume  also  contains  the  Transition  Phase  Analysis 
results,  which  is  the  transition  from  IUS  to  Tug  operations  The  analysis 
results  supported  the  Tug  costing  which  is  detailed  in  Volume  V All  Space 
Tug  data,  except  costing  details,  are  included  in  this  volume 

1 1 BACKGROUND 

The  Space  Transportation  System  will  include  a propulsive  stage  that  is 
carried  to  low  earth  orbit  by  the  Space  Shuttle  (Orbiter)  The  Space  Tug  will 
be  a newly  developed  vehicle  by  the  National  Aeronautics  and  Space  Administration 
for  use  by  both  NASA  and  DoD  projected  to  be  operational  in  1984  “The  expendable 
IUS  may  also  be  used  for  selected  missions  after  1984 

1 2 PURPOSE  AND  SCOPE 

The  Basic  purpose  of  this  phase  of  the  Orbital  Operations  Study  was  to  develop 
Tug  operational  concepts,  a Tug  Baseline  Operations  Plan,  and  to  provide  cost 
estimates  for  Space  Tug  operations.  An  overall  study  approach  for  the  Tug 
Operations  Phase  is  shown  in  Figure  1 2 0-1.  The  basic  Tug  study  approach  was 
to  compile  and  evaluate  baseline  concepts,  definitions  and  system,  and  to  use 
that  data  as  a basis  for  the  Tug  operations  phase  definition,  analysis  and 
costing  analysis  The  operational  analysis  led  to  the  Tug  operational  concepts 
and  the  Tug  Baseline  Operations  Plan  In  addition,  special  emphasis  trades 
and  the  transition  phase  analysis  were  performed 

Both  autonomy  level  II  and  III  configurations  were  analyzed  during  the  study 
The  Space  Tug  with  the  Two  autonomy  levels  were  developed  early  in  the  study 
to  provide  a basis  for  preliminary  costing  and  operations  evaluation  During 
the  latter  phases  of  the  study,  a basically  autonomous  Level  II  Tug  was  utilized 
for  major  emphasis  during  the  final  three  months  of  contracted  effort  Transi- 
tion phase  analysis  was  based  on  the  operational  activities  of  an  expendable 
IUS  (Level  B)  to  the  Space  Tug  (Level  II) 

The  major  emphasis  items  for  the  Orbital  Operations  study  was  on-orbit  operations 
and  interfaces  with  the  Orbiter,  the  Tracking  and  Data  Relay  Satellites,  ground 
station  support  capability  analysis,  and  flight  control  center  sizing  to 
support  the  Tug  mission  requirements. 

1 3 DOCUMENT  OUTLINE 

The  following  paragraphs  give  a brief  overview  of  the  type  of  information 
continued  in  each  of  the  sections  inluded  in  this  volume  of  the  final  report 
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Figure  1 2 0-1  IUS/T ug  Overall  Study  Approach 


• Section  2 0 - Gives  a summary  of  the  Tug  operational  and  interface 
requirements  with  emphasis  on  the  on-orbit  checkout  requirements. 

Tug  external  interface  operational  requirements,  safety  require- 
ments, and  Tug  system  operational  interface  requirements 

• Section  3 0 - Gives  a brief  summary  of  the  reference  missions 
baselined  for  the  Tug  and  details  for  the  mission  functional  flows 
and  timelines  derived  for  the  Tug  mission. 

I 

• Section' 4 0 - Gives  an  overview  of  the  Tug  subsystems,  with  emphasis 
on  component  description  and  characteristics  which  would  be  used 
for  flight  operations  analysis 

• Section  5 0 - Provides  the  operational  interfaces  definitions  for 
the  Tug  interface  with  the  Orbiter,  the  Spacecraft,  Ground  Control 
Center,  with  emphasis  on  the  Tug  Orbiter  operational  interfaces,  and 
Caution  & Warning  parameter  definitions. 

• Section  6 0 - Gives  a detailed  discussion  of  the  Tug  on-orbit 
operations  (pre  and  post  deploy)  prior  to  the  Tug  first  burn 
Items  emphasized  include  checkout  philosophy,  activation'  and 
monitoring  functions,  allocation  of  functions,  and  Orbiter  soft- 
ware impacts  to  support  the  Tug 

• Section  7 0 - Discussed  the  operations  related  to  Spacecraft 
deployment  and  retrieval  by  the  Tug.  Major  emphasis  in  this 
section  defines  Tug  support  during  rendezvous  and  docking 
operations 

• Section  8 0 - Gives  an  overview  of  the  STDN  and  TDRSS  characteris- 
tics/data flow,  an  analysis  of  the  communication  interface  support 
available  for  Tug  missions,  discussion  of  the  Tug,  Spacecraft,  and 
Orbiter  operations  center  interfaces,  and  an  analysis  of  potential 
problem  areas  in  the  design  of  a new  operations  center 

• Section  9 0 - Presents  the  Tug  Baseline  Operations  Plan  It 
contains  the  mission  plan  overview,  the  functional  organization  for 
flight  control  and  flight  support  personnel,  the  mission  control 
group  functions  and  definitions,  the  ground  and  flight  support 
hardware/software  descriptions  and  summaries  the  Tug  cost  estimates 
generated  during  the  study. 

• Section- 10  0 - Presents  the  IUS/Tug  operations  transition  defini- 
tions and  plan  with  summary  cost  data 

• Section  11  0 - Gives  an  overview  of  potential  problem  areas  or 
impact  areas  defined  during  the  Orbital  Operations  study 

• Section  12  0 - Gives  the  references  used  to  aid  in  the  development 
of  Volume  III 
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• Appendix  A - Gives  the  baseline  requirements  deleted  during  IUS/TUG 
Orbital  Operations  and  Mission  Support  Study. 

• Appendix  B - Presents  the  Space  Shuttle  C&W  definition  as  related 
to  Space  Tug. 
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2 Q OPERATIONAL  REQUIREMENTS  ANALYSIS 

The  purpose  of  the  operational  requirements  analysis  is  to  develop  an  under- 
standing of  Tug  Orbital  Operations  functions  and  to  provide  a requirement  package 
for  further  usage  The  summary  requirements  could  then  be  used  as  authority  as 
well  as  check  points  to  assure  NASA  requirements  had  been  accomplished  The  base- 
line requirements  had  to  be  assembled  and  interpreted  to  arrive  at  a clear  under- 
standing of  the  Tug  peculiar  problems  relative  to  Orbital  Operations  The  five 
main  areas  of  the  requirements  analyzed  were 

• Mission  Operations 

• SpaceTug  Interfaces 

• Space  Tug  Orbital  Checkout 

• Space  Tug  Safety  Critical  Operations 

• Space  Tug  Systems 

2 I MISSION  OPERATIONS  REQUIREMENTS  ANALYSIS  SUMMARY 

The  objective  of  analyzing  and  summarizing  mission  operations  requirements 
from  baseline  documentation  was  to 

• Perform  trades  and  sizings  with  authenticity  supported  by  the 
base!  me 

• Provide  traceability  of  study  conclusions  to  baseline  data 

• Perform  studies  at  the  greatest  level  of  detail  supportable  by 
baseline  documentation 

• Take  full  advantage  of  prior  study  results 

• Coordinate  this  study  with  concurrent  studies  through  adherence 
to  the  common  baseline 

Since  the  identification,  trading,  and  sizing  of  mission  operation  and  mission 
support  requirements  is  sensitive  to  the  time  of  occurrence  and  duration  of 
the  requirement,  the  Mission  Operations  Requirements  were  summarized  into 
timelines 

211  Generation  of  Mission  Operations  Timelines 

The  approach  taken  to  the  generation  of  these  Mission  Operations  Requirements 
Timelines  is  shown  in  Figure  2 1 1-1  Modular  building  blocks  which  can  be 
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Figure  2 1. 1-1  IUS,  Tug  Operational  Timeline  Generation  Flow 


sequentially  assembled  to  make  up  specific  Tug  missions  from  pre-launch  to 
landing  were  selected  from  IUS/Tug  Operational  Studies  performed  previously 
by  IBM  for  NASA  and  DoD  Next,  the  Baseline  Space  Tug  Flight  Operations  and 
System  Requirements  and  Guidelines  documents  were  carefully  analyzed  and  the 
pomt-of-departure  timeline  building  blocks  were  modified,  constrained,  and 
supplemented  to  incorporate  all  provisions  of  this  baseline  documentation 

Some  of  these  requirements  derived  from  baseline  documentation  were  in  the 
form  of  explicit  events  to  be  included  in  the  timelines  e g , "Tug  Mission 
Sequence  for  SC  Delivery  and  Retrieval",  page  29,  Figure  11  of  Volume  3, 

Baseline  Space  Tug  Flight  Operations  Other  requirements  for  mission  operations 
were  implied  from  baseline  documentation  e g , mam  engine  “enables'1  were 
added  to  timeline  building  blocks  to  implement  Volume  1 (Baseline  Space  Tug 
System  Requirements  and  Guidelines),  page  74,  Paragraph  4 requirements  for 
interlocks  to  prevent  inadvertent  operations  of  the  Spacecraft  while  in  the 
Orbiter  payload  bay  or  during  the  deployment  phase  of  operation  Similarly, 
Volumes  2 and  4 (Baseline  Space  Tug  Configuration  Definition  and  Baseline 
Space  Tug  Ground  Operations  Verification,  Analysis  and  Processing,  respec- 
tively) were  analyzed  for  implied  mission  operations  requirements  and 
appropriate  adaptions  were  made  in  the  pomt-of-departure  module  definitions. 
Further  resolution  was  added  to  the  resulting  Standard  Mission  Timeline 
Modules  by  incorporation  of  prior  Tug  Systems  Study  results  Next,  specific 
event  (e>  g , mam  engine  burn)  times  provided  by  the  Mission  Planner 
Program  were  placed  within  the  appropriate  Standard  Modules  and  the  resulting 
"Reference  Times"  within  the  modules  provided  for  their  sequencing  with  other 
modules  to  make  up  total  mission  timelines  This  process  yielded  standard 
timeline  modules  for  all  mission  phases  such  as  launch,  deployment,  and 
retrieval  which  were  keyed  to  times  within  specific  missions  It  also 
identified  detailed  activities  required  to  precede  and  follow  key  events  such 
as  the  initialization  of  GN&C  before  an  engine  burn  and  ground  tracking 
following  the  burn  Sequences  and  timing  of  these  supporting  activities  were 
then  determined  from  baseline  and  Tug  Systems  Study  documentation  to  place 
them  in  time  around  the  reference  times 

2.1  2 Special  Cases  in  Mission  Operations  Requirements  Derivation 

Determination  of  On-orbit  Service,  and  Abort  mission  operations  requirements 
and  timelines  necessitated  the  analysis  of  additional  documentation 
McDonnell  Douglass  documents  such  as  "IUS/Tug  Payload  Requirements  Compati- 
bility Study",  (1974)  were  analyzed  in  much  the  same  manner  as  described 
previously  for  the  baseline  documentation  The  limited  amount  of  On-orbit 
Servicing  Operations  definition  in  the  baseline  documentation  necessitated 
the  gathering  and  analysis  of  other  documentation  covering  several  of  the 
servicing  approaches  One  of  these  is  described  in  the  Tug  Operations  and 
Payload  Support  Study  Volume  3,  dated  March  1973  Another  approach  is  defined 
in  the  Payload  Utilization  of  Tug  report.  Volume  2,  June  1974  which  defined  a 
seven  element  service  timeline  module  using  a module-exchange  satellite  servicer 
This  was  adapted  to  be  non-specific  to  the  servicer  mechanisms  and  other  ser- 
vicing approaches  such  as  the  remote-manipulator  servicer  An  IBM  Standard 
Service  Module  was  defined  in  a flow  and  timeline  to  fit  within  the  IBM 
Standard  Docking  Module  and  the  IBM  Standard  Payload  Placement  Module  The 
reference  time  for  this  module  was  defined  as  the  completion  of  latch  between 
Tug  and  SC  (to  eliminate  overlap  in  the  micro-rendezvous)  Detailed  servicing 
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operational  requirements  were  implied  from  a careful  review  of  the  several 
servicing  approaches  and  generalization  of  the  IBM  Standard  Service  Module 
definition  to  allow  overall  compatibility  with  all  approaches  being  considered 

Baseline  Space  Tug  System  Requirements  & Guidelines  specifies  in  Paragraph 
3211131,  "The  Tug  shall  be  compatible  with  all  Shuttle  abort  modes  and 
procedures  specified  in  JSC  07700,  Volume  X and  XIV,  January  1974"  These 
documents  specified  abort  requirements  in  terms  of 

• Return  to  Launch  Site 

• Abort  Once  Around 

• Abort  to  Orbit 

• Abort  from  Orbit 

Operations  requirements  timelines  and  flows  referencing  agreement  with  the 
above  specifications  were  published  in  the  "Space  Tug/Shuttle  Interface 
Compatibility  Study,  September  1974"  Additional  information  on  abort  mission 
operations  requirements  was  derived  m the  study  "Gross  Abort  Effects  on  STS 
Elements"  and  was  published  in  Appendix  B of  "DoD/NASA  System  Impact  Analysis 
(Study  2 1)  Final  Report,  Volume  II,  September  1973  This  information  was 
used  in  generating  the  IBM  Standard  Abort  Module  flow  and  timeline  which 
interfaces  with  the  IBM  Standard  Launch  Module  and  the  IBM  Standard  Retrieval 
Module  It  conforms  to  the  abort  requirements  specifications  of  JSC  noted 
above  and  observes  mission  operational  requirements  specified  in  the  baseline 
documents  such  as  dump  time  contramts  and  thermal  conditions  for  abort 
situations  named  in  Baseline  Space  Tug  System  Requirements  and  Guidelines 
(Paragraph  32614) 

213  Assessment  of  Mission  Operation  Support  Requirements 

Flows  and  timelines  which  resulted  from  the  analysis  of  mission  operations 
requirements  were,  themselves,  analyzed  to  determine  their  implementation 
requirements  Several  assessments  were  made  under  differing  guidelines 
(such  as  those  which  distinguish  autonomy  levels)  More  than  100  potential 
implementation  requirements  were  considered  for  each  of  the  activities  in  the 
Standard  Timeline  Modules  These  were  assessed  for  each  of  the  implementing 
agencies  Space  Tug,  Network,  Orbiter,  TOC,  Payload,  SOC,  and  POC  The 
resulting  implementation  requirement  definitions  provide  the  means  for 
quantitative  evaluation  of  trade  studies  and  for  the  sizing  and  costing  of 
candidate  implementation  approaches 

2 2 SPACE  TUG  INTERFACE  OPERATIONAL  REQUIREMENTS  ASSESSMENT  SUMMARY 

This  section  summarizes  the  requirements  which  Orbital  Operations  places  on 
the  Space  Tug/external  interfaces  The  primary  intent  is  to  assure  all  base- 
line requirements  are  met  and  that  the  specific  problems  of  Orbital  Operations 
are  considered  in  the  existing  requirements 

The  requirement  number  used  is  the  same  number  used  throughout  this  study  and, 
therefore,  has  traceability  to  previous  data  exchanges  and  to  a baseline 
document  and  page  The  numerical  system  chosen  to  identify  requirements 
can  be  best  explained  by  an  example 
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0TI-1-17-140  (Requirement  Example) 

In  the  above  example,  OTI  represents  an  Orbiter/Tug  Interface  Requirement 
Designators  used  throughout  Section  2 0 are 

OTI  = Orbiter/Tug  Interface  (Used  in  Section  221) 

PTI  = Payload/Tug  Interface  (Used  in  Section  222) 

TGI  = Tug/Ground  Interface  (Used  in  Section  223) 

TS  = Tug  System  (Used  in  Section  2 5) 

The  initial  number  1,  m our  example,  is  a sequential  number  which 
has  been  arbitrarily  assigned  to  requirements  This  sequence  number -can  be 
used  to  identify  a requirement  within  the  IBM  numbering  sequence  system 
The  second  number,  17  in  our  example,  is  a document  identification  number 
which  corresponds  to  the  IBM  IUS/Tug  technical  library  The  MSFC  Space  Tug 
Baseline  Documents  have  been  assigned  the  following  document  identification 
number 

Volume  1 = 10 
Volume  2 = 16 
Volume  3 = 17 
Volume  4=15 

The  third  number,  140  is  the  page  in  the  baseline  document  where  the  require- 
ment will  be  found 

221  Space  Tug/Shuttle  Orbiter  Interface  Operational  Requirements  Assessment 

This  is  a summary  of  the  Space  Tug/Shuttle  Orbiter  Operational  Interface 
Requirements  as  defined  by  the  baseline  documentation  This  contains  the 
results  of  their  assessment  to  date  and  incorporates  actions  resulting  from 
data  exchange  meetings 

The  requirements  are  categorized  into  Implemented,  Concerns,  Implementation 
Undefined',  Deleted  and  Proposed  The  category  of  "Implemented"  contains  the 
requirements  upon  which  there  is  agreement  and  thus  are  being  implemented 
With  each  requirement  is  a statement  elaborating  on  implementation  The 
category  of  "Concern"  contains  the  requirements  that  cannot  be  or  are , not 
being  implemented  This  category  consists  mainly  of  conflicting  requirements 
and  includes  options  and  recommendations  The  category  of  "Implementation 
Undefined"  has  reasons  given  for  each  requirement  so  categorized  The 
category  "Deleted"  consists  of  those  requirements  removed  because  of  simi- 
larity, duplication  and  those  not  directly  affecting  the  operational  interface 
The  "Proposed"  requirement  category  contains  recommended  requirements  which 
became  apparent  during  the  assessment  of. the  existing  requirements 

2211  Operational  Requirements  Implemented 

The  following  requirements  are  those  where  there  is  agreement  and,  therefore, 
are  being  implemented  as  follows 

0TI-1 -17-139  The  Orbiter/Tug  operations  interface  will  be  kept  to  a minimum 
and  standardized 
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Implementation  - This  requirement  is  being  met  with  data  bus  technology, 
autonomy  II  Tug  design  and  Orbiter  operations  limited  essentially  to  safety 
and  contingency  situations 

OTI-5-17-141  Capability  shall  be  provided  for  Orbiter  crew  to  dump  hazardous 
Tug  fluids  and  vent  Tug  pressurants  overboard  through  the 
Orbiter  vent  system  with  the  payload  bay  either  open  or  closed 

Implementation  - Any  valve  is  accessable  from  the  keyboard  and  switches  are 
available  for  pressure  relief 

0TI-6-17-140  Tug  communications  to  the  ground  while  in  the  Orbiter  cargo 
bay  shall  be  by  relay  of  the  standard  Tug  telemetry  format 
through  the  Orbiter  communications  system 

Implementation  - Tug  will  conform  to  the  standard  Orbiter  TM  format  because 
it  is  user  of  that  system 

OTI-7-17-141  The  Tug  shall  be  capable  of  accepting  a state  vector  and 

attitude  update  from  the  Orbiter  prior  to  release  and  from  the 
ground  when  in  free  flying  mode 

Implementation  - Position  and  velocity  update  three  hours  before  injection 
and  or  attitude  update  15  minutes  before  injection  is  planned 

OTI-8-16-55  The  electrical  power  system  shall  be  started  from  the  ground 
with  emergency  shutdown  capability  from  the  Orbiter 

Implementation  - Tug  fuel  cells  will  be  activated  during  prelaunch  Stop  or 
start  of  the  electrical  power  system  can  be  accomplished  from  the  Orbiter  aft 
station  switch  and  via  the  R F link  from  either  the  ground  or  the  Orbiter 

0TI-9-10-19  The  baseline  Tug  while  in  the  payload  bay  shall  provide  systems 
status  data  to  and  receive  commands  from,  Tug/SC  Operations 
Center(s)  via  the  Orbiter  provided  communications  relay  as 
defined  in  JSC  07700 

Implementation  - Status  and  commands  will  be  exchanged  across  the  Orbiter/Tug 
interface  to/from  TOC,  however,  Orbiter  commitment  is  subject  to  operational 
mode  control  by  the  crew 

0TI-10-10-58  Internal  attitude  control  signal  of  the  Tug  shall  be  capable  of 
being  checked  for  accuracy  by  the  Orbiter  crew  before  release 

Implementation  - Tug  internal  attitude  control  signals  will  be  available  at 
the  Aft  Display  but  Orbiter  maneuvers  must  be  made  to  check  accuracy 

0TI-12-10-70  Spacecraft  shall  provide  caution  and  warning  data  to  the 

Orbiter  and  crew  for  safety  critical  functions  while  aboard 
or  in  the  near  vicinity  of  the  Orbiter 

Implementation  - The  Spacecraft  C&W  paths  to  the  Orbiter  exist  both  hardwired 
and  as  part  of  the  Tug  telemetry  data 


2-6 


OTI- 14-10-65  Positive  indications  of  Tug  electrical  systems  shut  down  status 

shall  be  provided  to  the  Orbiter  flight  crew,  prior  to 
retrieval 

Implementation  - Verification  light  on  the  panel  at  the  Aft  Station  indicates 
execution  of  the  command,  however,  fuel  cells  are  required  until  after 
retrieval 

0TI-15-10-63  Command  affecting  safety  critical  equipment  status  must  have 
associated  data  transmission  to  provide  a positive  functional 
verification. 

Implementation  -Verification  light  on  the  panel  at  the  Aft  Station  indicates 
execution  of  the  command 

0TI-17-10-62  Tug  propulsion  system  start  sequence  logic  status  and  valve 
positions  shall  be  monitored  and  message  signals  shall  be 
provided  at  the  Shuttle  Data  Management  Interface  Trans- 
missions shall  be  through  hardware  while  within  the  Orbiter 
bay  but  once  outside  it  may  be  transmitted  directly  from  the 
Tug 

Implementation  - Propulsion  logic  status  and  vaTve  positions  will  be  accessable 
from  keyboard  and  display  This  data  will  be  in  the  Tug  telemetry  data 

t 

0TI-18-10-58  Tug  attitude  shall  be  controlled  by  the  Orbiter  immediately 
following  release  during  deployment  and  before  retrieval  to 
preclude  possibility  of  collision  Control  distance  for 
deployment  and  retrieval  operations  is  TBD 

Implementation  - APS  will  be  operative  immediately  after  release  from  RMS 
The  Tug  will  hold  attitude  while  the  Orbiter  maneuvers 

0TI-19-10-51  No  single  Tug  failure  shall  result  in  a hazard  which  jeo- 
pardizes the  flight  or  ground  crews  of  the  Shuttle,  general 
public,  public/private  property  or  the  ecology 

Implementation  - Requires  dual  redundancy  and  is  being  implemented 

0TI-21-10-62  APS  shall  be  capable  of  being  shut  down  by  one  command  from 
the  Orbiter 

Implementation  - APS  shut  down  is  possible  with  switch  at  Aft  Station. 

OTI-22-10-20  The  Tug  (while  in  the  cargo  bay]  shall  relay  via  the  Orbiter,  SC 
operations  center  control  commands  as  required  for  mission 
preparations  Orbiter  safety  related  commands  to  the  SC  shall 
be  relayed  to  the  SC 

Implementation  - SC  telemetry  and  command  data  links  are  fed  thru  Tug  to  and 
from  the  Orbiter 

0TI-23-10-20  The  Tug  (while  in  the  cargo  bay)  shall  relay  SC  systems  status 
data  to  the  Orbiter  for  relay  to  SC  operations  center (s) 
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SC  systems  safety  data  shall  be  relayed  to  the  Orbiter  for 
caution/warmng 

Implementation  - SC  telemetry  is  fed  thru  Tug  and  Orbiter  for  relay  to  SCOC 
SC  safety  data  is  relayed  thru  the  Tug  to  the  Orbiter  C&W 

0TI-24-10-19  The  Tug  shall  have  the  capability  to  accept  changes  in  mission 
assignment  (not  including  SC  changeout),  target  or  SC  ephermeris 
up  to  within  two  hours  prior  to  launch 

Implementation  - Requires  memory  reload  and  verify  within  two  hours  which  is 
planned 

0TI-25-10-19  The  baseline  Tug  while  in  the  payload  bay  and  during  Tug/SC/ 
Orbiter  deployment/retrieval  operations  shall  provide  safety 
critical  status  data  to,  and  receive  overriding  corrective 
commands  or  safing  commands  from,  the  Orbiter  and  Tug/SC  Opera- 
tions Center(s)  The  system  shall  be  compatible  with  the 
standard  Orbiter  warning  displays  and  devices.  Tug  Operations 
Center  will  provide  back-up  monitoring  and  command  of  all 
safety  functions  Normal  Tug  operations  shall  not  require 
controls  in  the  Orbiter  except  for  (1)  emergency  safing, 

(2)  safety  interlocks,  (3)  deployment  and  retrieval  operations, 
and  (4)  activation/deactivation  There  is  no  requirement  for 
Orbiter/Tug  communications  following  deployment  operations 
until  Tug/Orbiter  rendezvous  and  retrieval  operations  begin 

Implementation  - The  requirement  to  monitor  and  allow  override  of  safety  items 
is  implemented  with  Orbiter  prime  and  TOC  back-up 

0TI-26-10-19  The  Tug  shall  provide  flight  program  memory  verification  data 
to  and  receive  memory  load  updates  from  the  Tug  operations 
center  via  relay  by  the  Orbiter  while  in  the  Orbiter  payload 
bay 

Implementation  - Memory  reload  and  verify  thru  Orbiter  is  planned 

0TI-28-10-28  After  physical  separation  from  the  Orbiter,  the  Tug  shall 

maintain  a stable  attitude  consistent  with  Orbiter  deployment 
mechanism  tipoff  rates  until  a safe  Orbiter-Tug  separation 
distance  and  confirmed  mission  readiness  have  been  accomplished 

Implementation  - APS  will  be  operative  immediately  after  release  from  RMS 
The  Tug  will  hold  attitude  while  the  Orbiter  maneuvers. 

0TI-30-10-45  Mission  critical  single  failure  points  will  be  minimized  to  the 
maximum  extent  possible 

Implementation  - Mission  critical  single  failure  points  will  be  minimized  as 
a goal 

OTI-32-10-20  The  Tug  shall  be  capable  of  receiving  secure  commands  from  and 
transmitting  secure  data  to  the  Orbiter  and  Tug/SC  operations 
center (s)  The  Tug  shall  be  capable  of  transmitting  commands 
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to  the  Spacecraft  and  receiving  data  from  the  Spacecraft 
The  communications  system  shall  be  Space  Ground  Link  System 
(SGLS)  compatible  and  shall  permit  encryption-decryption 
capability 

Implementation  - SC  telemetry  and  command  data  links  are  fed  thru  Tug  to  and 
from  the  Or biter,  are  SGLS  compatible  and .permit  encryption  and  decryption 

0TI-33-10-21  Electrical  power  for  Tug/SC  is  available  from  the  Orbiter  ■ 
electrical  power  system  An  electrical  energy  allowance  of 
50  kilowatt-hours  (kwh), is  dedicated  for  Tug/SC  support  wrth 
energy  m excess  of  this  allocation  being  mission  dependent 
and  capable  of  being  supplemented  by  additional  consumables 
to  the  Orbiter  fuel  cells  and/or  by  independent  Spacecraft 
systems  This  power  is  in  the  form  of  regulated  redundant 
28  V DC  Power  levels  and  regulation  shall  be  as  specified  in 
JSC  07700  Volume  XIV 

Implementation  - Electrical  power  for  Orbiter  to  Tug  is  being  utilized  and 
will  require  power  transfer  prior  to  deployment  operations  of  the  Tug  and' 
the  Spacecraft 

l 

0TI-35-10-46  Isolation  of  anomalies  of. mission  and,  crew  essential  functions 
will  be  provided  to  assure  a failure  ynll  not  propagate 
across  any  interface  During  ground  operations,  capability  to 
fault  isolate  to  the  line  replaceable  unit  (or  group  of  units) 
without  disconnections  or  use  of  carry-on  equipment,  shall  be 
provided 

Implementation  - Isolation  of  anomalies  to  prevent  crossing  interfaces  and  to 
LRU  must  be  treated  as  a goal 

0TI-36-10-54  All  mechanical,  electrical  and  fluid  connections  between  the 
Tug  and  Spacecraft  and  Orbiter  shall  be  fail  safe 

Implementation  - Dual  redundancy  is  being  implemented 

\ 1 

OTI-37-10-54  Provisions  shall  be  made  -to  confirm  that  all  safety  critical 
Orbiter/Tug  electrical  connections,  fluid  lines,  etc  , inter- 
faces are  securely  connected 

Implementation  - Interlocks  on  all  safety  critical  interfaces  are  being 
imp! emented 

0TI-38-10-54  No  single  failure  shall  result  in  unprogrammed  motion  of  the 
Tug  while  aboard  the  Orbiter,  during  deployment  within  TBD 
distance  of  the  Orbiter ,<  or  during  retrieval  of  the  Tug 

Implementation  - Dual  redundancy  m Flight  Control  System  hardware  is  being 
implemented 

0TI-39-10-54  As  a minimum.  Tug  shall  be  designed  .to  sustain  a failure  and 

retain  the  capability  to  successfully  terminate  the  Tug  functions 
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without  injuring  flight  personnel  or  damaging  the  Orbiter  or 
other  payloads  (fail-safe) 

Implementation  - This  requires  dual  redundancy  which  is  being  implemented 

QTI-40-10-54  Tug  operations  and  energy  levels  shall  be  held  to  a minimum 
while  aboard  or  in  the  near  vicinity  of  the  Orbiter 

Implementation  - Operations  and  energy  levels  are  being  held  to  a minimum  as 
a goal 

0TI-42-10-62  Interlocks  shall  be  provided  to  assure  that  propulsion  systems 
will  not  be  fired  while  in  the  Orbiter  payload  bay  and  that  no 
single  operation  shall  result  m propellants  being  dumped  in 
the  payload  bay 

Implementation  - Propulsion  will  be  interlocked  safe  with  power  buses  con- 
trolled by  switches  at  the  Aft  Station 

0TI-43-10-63  Message  signals  for  Tug  system,  by  hardwire  and  RF  telemetry, 
shall  be  provided  at  the  Shuttle  Data  Management  System 
Interface  Measurements  shall  include  Tug  latched/released 
indications,  deploy  mechanism  position  indications,  discrete 
pyrotechnic  event  indications,  sequence  logic  status,  valve 
positions,  temperature  and  pressure  measurements,  and  failure 
indications  This  information  should  also  be  available  prior 
to  retrieval 

Implementaion  - Data  requested  is  being  provided  by  a combination  of  C&W  dis- 
play and  keyboard/display  Data  is  provided  by  a combination  of  hardwire 
and  as  part  of  the  Tug  telemetry  data 

0TI-57-10-70  Provisions  shall  be  made  to  confirm  that  all  safety  critical 
Spacecraft/Tug  interfaces  are  securely  connected  prior  to 
retrieval  of  Tug 

Implementation  - Spacecraft/Tug  interfaces  are  interlocked  and  summarized  as 
a C&W  displayed  parameter 

OTI-62-10-75  RF  communcation  capability  shall  be  available  between  the 
Orbiter  and  the  Spacecraft  for  safety  related  command  and 
control  functions  while  detached  from  the  Orbiter  and  up  to 
a separation  distance  of  TBD 

Implementation  - There  will  be  cornmum cations  capability  between  the  Orbiter 
and  the  Spacecraft  (via  the  Tug)  for  safety  related  command  and  control  while 
attached,  detached  from  the  Orbiter,  up  to  a separation  distance  of  20  NM 

OTI-64-10-75  Automatic  event  sequencing  programs  and  automatic  controls 

whose  actuation  could  affect  flight  personnel  safety  shall  be 
operative  only  by  the  Orbiter,  or  by  ground  control  enabling 
switches  (command  over-ride),  e g , pyrotechnic  sequences, 
automatic  deployment  sequences,  etc 
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Implementation  - Orbiter  prime  and  ground  back-up  control  of  safety  items  is 
provided 

2212  Operational  Requirements  Concerns,  Options  and  Recommendations 

The  following  requirements  are  those  which  can  not  be  or  are  not  being  imple- 
mented With  each  stated  requirement  is  given  the  reason  for  concern,  the 
options  to  alleviate  the  concern  and  the  recommendation  to  close  out  the  issue 

Requirement  No  2 and  29 

QTI-2-17-139  A Tug  automatic  caution  and  warning  system  will  be  provided  to 
alert  the  Orbiter  to  hazardous  conditions  in  the  Tug  when 
attached  or  within  TBD  miles  of  the  Orbiter  This  system 
shall  interface  with  the  standard  Orbiter  caution  and  warning 
displays  and  warning  devices 

i 

0TI-29-10-45  (1)  All  subsystems  except  primary  structure  and  pressure 

vessels  shall  be  designed  to  fail  safe  in  the  'Vicinity 
of  the  Shuttle  Oribter 

(2)  All  safety  subsystems  shall  be  designed  to  fail  opera- 
tional in  the  vicinity  of  the  Shuttle  Orbiter 

t Concern 

Detached  Tug  C&W  data  flow  path  is  simplex  at  Orbiter  Payload 
Data  Interleaver  as  presently  defined 

■ Options 

Orbiter  design  change  to  implement  redundant  data  paths  thru 
Payload  Data  Interleaver 

Procedural  change  to  implement  an  Orbiter  evasive  maneuver  to 
safe  distance  and  ground  activation,  checkout  of  Tug/Spacecraft 

If  checkout  OK  then  proceed  with  mission 

ff  checkout  not  0K_ then  ground  will  safe  Tug/Spacecraft  and 
Orbiter  will  retrieve  Tug/Spacecraft  if  possible. 

• Recommendation 

Procedural  change  provides  satisfactory  technical  solution 
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Requirement  No  3 


OTI-3-17-140  Design  Tug  so  it  can  be  jettisoned  in  orbit  by  command  from 
Orbiter  or  ground  for  emergency  reasons  Provide  emergency 
deploy  and  release  of  Tug  to  Orbiter  connections 

t Concerns 

Currently  not  in  baseline  design 

IBM/GDC-I/MSFC  have  discussed  issue  and  have  assumed  jettison 
equates  to  normal  Tug  deployment 

What  is  minimum  deploy  time  for  emergency  conditions7 

Are  there  Tug  system  failures  which  can  manifest  themselves 
prior  to  the  minimum  deploy  time7 

• Recommendations 

JSC/MSFC  should  define  minimum  deploy  time  for  emergency 
conditions 

Space  Tug  studies  should  define  system  failures  that  could 
occur  prior  to  minimum  time  and  design  protection  against 
identified  failures 


Delete  Requirement  No  3 
Requirement  No.  20 

0TI-20-10-51  The  proper  functioning  of  the  interface  between  the  STS  and 
Tug  shall  be  maintained  under  all  nominal,  contingency,  and 
emergency  operations  of  either  the  STS  or  the  Tug 

• Concern 

Detached  Tug  data  flow  path  is  simplex  at  Orbiter  Payload  Data 
Interleaver 

e Options 

Orbiter  design  change  to  implement  redundant  data  paths  thru 
Payload  Data  Interleaver 

Procedural  change  (same  as  Requirement  No  2 and  29) 

$ Recommendation 

Procedural  change  (same  as  Requirement  No  2 and  29) 
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Requirement  No  27 


0TI-27-10-28  The  Tug  shall  not  initiate  its  propulsion  system  until  a 
safe  separation  distance  and  attitude  relationship  between 
Orbiter  and  Tug  is  achieved  ThetIug~propulsion  system  shall 
not  cause  impingement  of  exhaust  gases  that  would  be  harmful 
to  the  Orbiter 

• Concerns 

APS  will  be  activated  shortly  after  physical  deployment 

It  is  assumed  the  requirement  statement  is  applicable  to  main 
propulsion  system  only 

• Recommendations 

Restate  requirement  for  application  to  main  propulsion  system 
only 

Requirement  No  44 

0TI-44-10-63  Tug  critical  command  and  control  circuitry  shall  be  designed 
to  be  fail  operational /fail  safe  as  a minimum 

■ Concerns 

Requirement  statement  for  fail  operational/fail  safe  stated 
in  MSFC  Baseline  document 

First  Data  Exchange  recommendation  was  stated  as  “No, Single., 
Point  Failure  Shall  Result  in  a Hazard  which  Jeopardizes  the 
Flight  or  Ground  Crew" 

No  indication  of  fail  safe  design  in  Avionics  or  operational 
interface 

■ Recommendation 

MSFC  needs  to  restate  current  requirement  for  contractor 
- guidance 

Requirement  No  45 

0TI-45-10-63  Tug  autonomous  navigation  commands  for  attitude  control  and 

translation  maneuvers  shall  be  disabled  until  a safe 
„ separation  distance  and  compatible  trajectories  can  be  verified 

• Concerns 

APS  (attitude  hold)  will  be  activated  shortl.yiafter  physical 
deployment 
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Requirement  statement  implies  no  commands  for  attitude  holds 
• Recommendation 

Restate  requirement  to  exclude  attitude  hold  activation 

2213  Operational  Requirements  Implementation  Undefined 

The  following  requirements  are  those  which  implementation  is  not  currently 
defined 

OTI-4-17-141  Provision  shall  be  made  to  redump  any  recorded  data  in  the 
event  that  a data  dump  is  unsuccessful 

Assessment  - This  requires  a recorder  with  replay  feature  or  loop  and  confirm 
receipt  before  erase  feature  This  is  undefined 

OTI-11-10-70  Any  Spacecraft  subsystem  operation  which  impacts  safety  during 
the  launch  and  entry  phases  shall  be  monitored  via  C&W 
(caution  and  warning)  and  controlled  from  the  Orbiter  flight 
station 

Assessment  - Spacecraft  C&W  is  defined  as  35  functions  and  crew  control  is 
defined  as  94  discretes,  however,  operational  details  of  what  is  displayed 
and  controlled  is  not  defined 

0TI-34-10-22  The  Tug  shall  be  compatible  with  all  Shuttle  abort  modes  and 
procedures  specified  in  JSC  07700,  Volumn  X and  XIV 

Assessment  - Tug  compatibility  with  very  limited  definition  of  Shuttle  abort 
modes  cannot  be  fully  defined 

OTI-60-10-75  Spacecraft  propulsion  system  start  sequence  logic  status,  and 
valve  positions  shall  be  monitored  and  message  signals  shall 
be  provided  at  the  Shuttle  Data  Management  System  interface 
The  transmission  shall  be  through  Tug  hardware  while  within 
the  payload  bay  but  once  outside  it  may  be  transmitted  either 
directly  from  the  Spacecraft  or  via  the  Tug  telemetry  system 

Assessment  - The  Spacecraft  two-way  communication  path  with  the  Orbiter  exists, 
message  signal  content  detail  is  undefined 

0TI-61-10-75  Message  signals  from  Spacecraft  systems  shall  be  provided  at 
the  Shuttle  Data  Management  System  Interface  Measurements 
shall  include  at  least  Spacecraft  latched/released  indica^ 
tion,  deploy  mechanism  position  indications,  discrete 
pyrotechnic  event  indications,  sequence  logic  status,  valve 
positions,  temperature  and  pressure  measurements,  and  failure 
indications 

Assessment  - The  Spacecraft  two-way  communication  path  with  the  Orbiter  exists, 
message  signal  content  detail  is  undefined  A C&W  liqht  is  allocated  to 
Spacecraft  latch  and  deploy  mechanism  called  "Spacecraft  Arm/Safe". 
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2214  Operational  Requirements  Deleted 

The  following  18  requirement  numbers  are  those  which  have  been  deleted  from 
further  consideration  because  most  are  operationally  duplicates  or  have  no 
impact  on  operational  functions  See  Appendix  A Section  1 0 for  requirement 
statements  and  reasons  for  deletion 


DELETED  REQUIREMENT  NUMBERS 


0TI-13-10-66 
0TI-16-10-63 
0TI-31-10-45 
0TI-41-10-61 
OTI-46-10-63 
0TI-47  -10-64 


OTI-48-10-64 
0TI-49-10-64 
0TI-50-10-64 
0TI-51-10-64 
OTI— 52-10-64 
OTI "53 -10-64 


0TI-54-10-65 
OTI -55-10-65 
0TI-56-10-71 
0TI-58-10-74 
0TI-59-10-74 
0TI-63-10-77 


2215  Operational  Requirements  Proposed 

The  following  requirements  have  been  defined  from  the  analysis  of  the  Space  Tug 
operations  and  are  proposed  to  be  added  to  the  baseline. 

1 System  Level  Checkout  Requirement 

'Consistent  with  Level  II  autonomy  Tug  design  baseline  and- with  the  state- 
of-the-are  in  Built-in-Test-Equipment  (BITE),  it  is  a Tug  requirement 
to  be  primarily  responsible  for  system  level  checkout  as  part  of  redun- 
dancy management  The  Tug  Operations  Center  (TOC)  will  be  primarily 
responsible  for  detailed  status  keeping 

2 Classified  Payloads 

In  the  event  a classified  payload  is  retrieved  it  may  be  desirable  to 
remove  part  or  all  of  it  from  the  Tug  while  in  the  cargo  bay  Some  form 
of  requirement  will  be  necessary  to  handle  such  a situation.  In  general, 
no  requirement  addresses  just  what  the  Orbiter  is  to  do  with  classified 
pay! oads 

This  situation  could  impact  mission  planning  if  the  Tug  were  ever  required 
to  deploy  an  unclassified  but  retrieve  a classified  payload 

2 2 2 ► Space  Tug/Spacecraft  Interface  Operational  Requirements  Assessment 

This  is  a summary  of  the  Spacecraft/Tug  operational  interface  requirements 
as  defined  by  the  baseline  documentation  The  following  paragraphs  contain 
the  results  of  this  assessment  and  incorporate  actions  resulting  from  data 
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exchange  meetings  The  requirements  are  categorized  into  Implemented, 

Deleted  and  Exceptions  The  category  of  "Implemented11  contains  the  require- 
ments upon  which  there  is  agreement  and  thus  are  being  implemented  In  some 
cases,  however,  there  is  not  a total  operational  definition  possible  from 
available  companion  studies  With  each  requirement  is  a statement  elaborating 
the  implementation  The  category  of  "Deleted"  consists  of  those  requirements 
removed  because  of  similarity,  duplication  and  those  not  directly  effecting 
the  operational  interface.  The  "Exception"  category  consists  of  those  require- 
ments where  there  is  not  agreement  and  exception  is  being  taken  Rationale 
is  given  for  the  exception 

2221  Operational  Requirements  Implemented 

The  following  are  requirements  where  there  is  agreement  and,  therefore,  are 
being  implemented  as  stated 


PT1-1-17-140  Capability  shall  exist  for  ground  initiation  of  all  control 
signals  to  the  SC  interface 


Implementation  - The  ground  can,  through  the  Orbiter  and/or  Tug  2 KBPS  command 
uplink,  initiate  any  control  signals  to  the  SC  interface. 


PTI-2-10-70  Provisions  shall  be  made  to  confirm  that  all  safety  critical 
Spacecraft/Tug  interfaces  are  securely  connected  prior  to 
retrieval  of  Tug 


Implementation  - Spacecraft  arm/safe  is  displayed  on  the  Orbiter  C&W  panel 

PTI-3-10-38  The  Spacecraft  will  have  its  own  checkout  system 

Implementation  - The  Spacecraft  will  do  a complete  self  test  and  report  results 
through  the  Tug  and  Orbiter  (if  in  the  bay)  to  the^  ground 


PTI-4-10-20  The  Tug  shall  provide  limited  sequencing  as  required  to  the  SC 
prior  to  Tug/SC  separation 


Implementation  - The  Tug  will  provide  identified  operational  sequencing  of  the 
Spacecraft  prior  to  Tug/SC  separation 


PTI-6-10-16  SC  location,  initialization,  spin-up  and  release  are  performed 
automatically  Prior  to  deployment,  Tug  monitors  go/no  go  SC 
status  and  thruputs  SC  telemetry  to  the  ground 

Implementation  - The  Tug  is  planned  to  provide  these  required  services  to  the 

Spacecraft 

PTI-7-10-20  The  Tug  shall  be  capable  of  receiving  secure  commands  from 
and  transmitting  secure  data  to  the  Orbiter  and  Tug/SC  oper- 
ations center(s)  The  Tug  shall  be  capable  of  transmitting 
commands  to  the  Spacecraft  and  receiving  data  from  the  Space- 
craft The  commim cations  system  shall  be  Space  Ground  Link 
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Systems  (SGLS)  compatible  and  shall  permit  encryption-decryp- 
tion capability 

Implementation  - The  Tug  will  provide  two-way  conmum cation  between  SC  and  Tug/ 
SC  operation  centers  It  will  be  Space  Ground  Link  Systems  (SGLS)  compatible 
with  encrypt! on- decrypt! on  capability 

PTI-8-10-20  The  data  link  between  Tug  and  SC  during  any  part  of  the  mission 
shall  be  by  hardline  only 

Implementation  - There  are  only  hardwire  links  between  the  SC  and  the  Tug’,  no 
RF  link  is  planned 

PTI-9-10-20  The  Tug  shall  relay  SC  systems  status  data  to  the  Orbiter  for 
relay  to  SC  operations  center(s)  SC  systems  safety  data 
shall  be  relayed  to  the  Orbiter  for  cauti on/warm ng 

Implementation  - SC  system  status  is  relayed  thru  the  Tug  and  Orbiter  to  SCOC 
SC  system  safety  data  is  relayed  to  Orbiter  C&W 

PTI-11-10-21  «.  The  Tug  shall  provide  to  the1  SC  (single  or  multiple)  300  to 

600  watts  of  28  volts  DC  electric  power  during  the  Tug/SC 
orbit  transfer  phase.  The  total  electric  energy  shall  be  TBD. 
SC  requirements  for  electric  power  other  than  28  VDC  shall  ! 
be  provided  by  the  SC. 

Implementation  - Tug  is  providing  power  to  the  SC  This  requires  a power 
transfer  prior  to  SC  deploy  and  effects  Tug/SC  interface. 

PTI-12-10-21  Electrical  power  for  Tug/SC  is  aval  Table  from  the  Orbiter 
electrical  power  system  An  electrical  energy  allowance  of 
50  kilowatt-hours  (Kwh)  is  dedicated  for  Tug/SC  support  with 
energy  in  excess  of  this  allocation  being  mission  dependent 
and  capable  of  being  supplemented  by  additional  consumables, 
to  the  Orbiter  fuel  cells  and/or  by  independent  Spacecraft 
systems  This  power  is  m the  form  of  regulated  redundant 
28  V DC  Power  levels  and  regulation  shall  be  as  specified 
in  JSC  07700  Volume  XIV 

Implementation  - Orbiter  is  providing  power  to  Tug  and  SC  This,  similar  to 
No  11,  again  requires  a power  transfer  prior  to  SC  deploy  and  effects  Tug/SC 
interface 

PTI-13-10-38  Critical  and  hazardous  Tug  and  Spacecraft  checkout  systems 

and  functions  will  be  controlled  through  Orbiter  mterface(s) 

Implementation  - Orbiter  control  is  required  for  critical  and  hazardous  SC 
checkout  systems  and  functions  The  SC  has  stated  94  discretes  are  required 
at  the  Tug/SC  interface  and  that  some  are  Orbiter  controlled  but  no  operational 
detail  exists 
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PTI-14-10-45 


All  subsystems  except  primary  structure  and  pressure  vessels 
shall  be  designed  to  fail  safe  in  the  vicinity  of  the  Shuttle 
Orbiter  All  safety  subsystems  shall  be  designed  to  fail 
operational  in  the  vicinity  of  the  Shuttle  Orbiter 

Implementation  - Requires  fail  operational  design  of  Tug/SC  interface  which 
is  being  implemented  with  a redundant  design 

PTI-20-10-70  Spacecraft  shall  provide  caution  and  warning  data  to  the 

Orbiter  and  crew  for  safety  critical  functions  while  aboard 
or  in  the  near  vicinity  of  the  Orbiter 

Implementation  - This  differs  from  No  9 by  adding  the  requirement  to  provide 
SC  C&W  data  to  Orbiter  while  in  the  vicinity  of  the  Orbiter  The  Tug  telemetry 
data  is  radiated  to  the  Orbiter  while  in  the  vicinity  and  contains  SC  C&W  data 

PTI-30-10-78  The  arming  of  pyrotechnic  devices  shall  be  protected  against 
accidental  operations 

Implementation  - The  arming  of  pyrotechnic  devices  will  be  done  just  prior  to 
use  They  will  be  interlocked  while  in  the  cargo  bay  and  in  the  vicinity  of 
the  Orbiter  Status  of  interlocks  will  be  available  to  the  Orbiter 

PTI-32-10-78  Sequence  logic  and  pyrotechnic  firing  circuits  shall  be  at 
least  dual  redundant 

Implementation  - Interface  sequencing  logic  and  pyrotechnic  firing  circuits 
are  defined  as  redundant 


PTI-33-10-79  Provisions  shall  be  made  for  safing  on  command  unused  explosive 
devices  aboard  the  Spacecraft  and  safing  verification  sent 
to  the  orbiter  prior  to  retrieval 


Implementation  - Interface  design  is  planned  to  provide  the  above 

PTI-34-10-75  Message  signals  from  Spacecraft  systems  shall  be  provided  at 
the  Shuttle  Data  Management  System  interface  Measurements 
shall  include  at  least  Spacecraft  latched/released  indications, 
deploy  mechanism  position  indications,  discrete  pyrotechnic 
event  indications,  sequence  logic  status,  valve  positions, 

‘ temperature  and  presure  measurements,  and  failure  indications 

Implementation  - SC  status  will  be  relayed  thru  the  Tug  to  the  Orbiter  Thru 
the  telemetry  system  it  will  be  available  for  display  in  the  Orbiter  To  call 
out  specifically  that  all  of  these  operational  measurements  will  be  available 
is  beyond  the  level  of  detail  available  at  this  time. 


PTI-35-10-75  RF  communication  capability  shall  be  available  betwen  the 
Orbiter  and  the  Spacecraft  for  safety  related  command  and 
control  functions  while  detached  from  the  Orbiter  and  up  to  a 
separation  distance  of  TBD 

Implementation  - There  will  be  communications  capability  between  the  Orbiter 
and  the  Spacecraft  (via  the  Tug)  for  safety  related  command  and  control  while 
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attached,  detached  from  the  Orbiter,  up  to  a separation 
distance  of  20  NM. 


PTI-36-10-75  Automatic  event  sequencing  programs  and  automatic  controls 

whose  actuation  could  affect  flight  personnel  safety  shall  be 
operative  only  by  the  Orbiter,  or  by  ground  control  enabling 
switches  (command  over-ride),  e g , pyrotechnic  sequences, 
automatic  deployment  sequences,  etc 

Implementation  - Actuation  of  items  which  effect  personnel  safety  will  be 
interlocked  and  enabled  only  by  Orbiter  or  by  ground  control  when  conditions 
are  safe 

PTI-37-10-75  Commands  affecting  safety  critical  equipment  status  must  have 
associated  data  transmission  to  provide  a positive  functional 
verification. 

Implementation  - Commands  affecting  safety  critical  status  have  feedback  trans- 
mitted to  indicate  functional  verification 

PTI-38-10-75  Spacecraft  propulsion  system  start  sequence  logic  status,  and 
valve  positions  shall  be  monitored  and  message  signals  shall 
be  provided  at  the  Shuttle  Data  Management  System  interface 
The  transmission  shall  be  through  Tug  hardware  while  within 
the  payload  bay  but  once  outside  it  may  be  transmitted  either 
directly  from  the  Spacecraft  or  via  the  Tug  telemetry  system 

Implementation  - Spacecraft  propulsion  start  logic  and  valve  positions  will 
be  available  via  telemetry  and  Orbiter  display  The  transmission  will  be  via 
Tug  or  direct  from  Spacecraft 

2.2  2 2 Operational  Requirement  Exception 

The  following  is  a requirement  where  there  is  not  agreement  and  exception  is 
taken  Rationale  is  given  for  the  exception 

• Requirement  from  Baseline  System  Requirements  and  Guidelines 
Volumes  1,  Paragraph  326  2.3  d (8) 

PTI-39-10-75  Spacecraft  autonomous  navigation  commands  for  attitude  control 
and  translation  maneuvers  shall  be  disabled  until  a safe 
separation  distance  (TBD)  from  the  Tug  and  compatible  tra- 
jectories can  be  verified 

Rationale  - Attitude  control  must  be  enabled  immediately  after  deploy  to  hold 
attitude  and  minimize  tip  off  rates 

2 2.2  3 Operational  Requirements,  Deleted 

The  following  21  requirement  numbers  are  those  which  have  been  deleted  from 
further  consideration  because  most  are  operationally  duplicate  or  have  no 
impact  on  operational  functions.  See  Appendix  A Section  2.0  for  requirement 
statements  and  reasons  for  deletion 
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DELETED  REQUIREMENTS  NUMBERS 


PTI-5-10-20 

PTI-21-10-70 

PTI— 28-10-77 

PTI-10-10-20 

PTI-22-10-61 

PTI-29-10-78 

PTI-15-10-45 

PTI-23-10-64 

PTI-31-10-78 

PTI-16-10-45 

PTI-24-10-64 

PTI-40-10-74 

PTI— 17-10-46 

PTI-25-10-64 

PTI-41-10-74 

PTI-18-10-54 

PTI-26-10-64 

PTI-42-10-71 

PTI— 19-10-70 

PTI-27-10-76 

PTI-43-10-71 

22.3  Space  Tug/Ground  Control  Interface  Operational  Requirements  Assessment 

This  is  a summary  of  the  Space  Tug/Ground  Control  Operational  Interface  Require- 
ments as  defined  by  the  baseline  documentation  The  following  paragraphs 
contain  the  results  of  this  assessment  and  incorporate  actions  resulting  from 
data  exchange  meetings  The  requirements  are  categorized  into  Implemented, 
Deleted  and  Exceptions  The  category  of  "Implemented"  contains  the  requirements 
upon  which  there  is  agreement  and  thus  are  being  implemented  In  some  cases, 
however,  there  is  not  a total  operational  definition  available  from  companion 
studies  With  each  requirement  is  a statement  elaborating  the  implementation 
The  category  of  "Deleted"  consists  of  those  requirements  removed  because  of 
similarity,  duplication  and  those  not  directly  effecting  the  operational 
interface  The  "Exception"  category  consists  of  those  requirements  where 
there  is  not  agreement  and  exception  is  being  taken  Rationale  is  given  for 
the  exception 

2231  Operational  Requirements  Implemented 

The  following  are  requirements  where  there  is  agreement  and,  therefore,  are 
being  implemented  as  stated 

TGI-1-17-40  Tug  flight  operations  shall  be  compatible  with  NASA  operation 
requirements  and  concepts  for  Tug  (NASA  Tug  Operations  Concept 
Document  - TBDJ 

Implementation  - The  document  is  TBD  because  this  study  is  originating  a 
recommended  plan  and  will  be,  therefore,  compatible 

TGI-2-17-122  The  Tug  Operations  Center  will  have  the  capability  to  initiate 
Tug  safing  prior  to  Orbiter  capture 

Implementation  - The  TOC  will  command  the  initiation  of  Tug  safing  prior  to 
Orbiter  Retrieval 

TGI -3-17-112  The  Orbiter  crew  will  perform  the  Tug  propellant  dump  required 
for  any  mission  abort  prior  to  Tug  release  Backup  command 
capability  will  be  from  ground  control 
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Implementation  The  Orbiter  crew  will  initiate  Tug  propellant  dump  with  the 
TOC  as  backup. 

TGI-4-17-139  A Tug  automatic  caution  and  warning  system  will  be  provided 
to  alert  the  Orbiter  to  hazardous  conditions  in  the  Tug  when 
attached  or  within  TBD  miles  of  the  Orbiter  This  system 
shall  interface  with  the  standard  Orbiter  caution  and  warning 
displays  and  warning  devices.  Ground  control  will  provide 
backup  monitoring  of  all  crew  safety  functions 

Implementation  - The  ground  (TOC)  is  prime  evaluator  of  Tug  detailed  status, 
therefore,  it  is  backup  monitoring  all  crew  safety  functions 

TGI-9-10-58  Tug  propellant  tank  integrity  shall  be  verified,  pressures 
and  hazardous  fluid  quantities  shall  be  reduced  to  a safe 
value,  and  ordnance  circuits  shall  be  safed  before  Tug  retrie- 
val operations  begin 

Implementation  - The  ground  is  prime  in  maintaining  detailed  Tug  status  at  all 
times  and  will  provide  this  verification 

TGI-10-10-31  The  Tug  shall  be  capable  of  performing,  within  the  mission 
durations  of  Paragraph  3 2 1 1 C,  Baseline  Volume  1,  post 
deployment  visual  inspections  of  SC  to  insure  SC  mission 
preparations  are  adequate 

Implementation  - The  Tug  will  perform  a visual  inspection  of  the  deployment 
Spacecraft  via  the  Tug  TV  monitor  and  relay  data  to  the  ground  to  insure 
Spacecraft  mission  preparations  are  adequate 

TGI-11-10-29  The  Tug/SC  shall  be  placed  m a safe  condition  and  verified 
by  Tug  operations  center  prior  to  reaching  the  minimum  safe 
distance  of  TBD  prior  to  docking  with  the  Orbiter 

Implementation  - The  ground  is  prime  in  monitoring  detailed  Tug  status  at  all 
times 

TGI-15-10-16  Tug  Telemetry  (Downlink)  will  provide  secure  events  and  analog 
parameters  when  stored  limits  exceeded 

Implementation  - The  ground  is  prime  in  monitoring  detailed  Tug  status  at  all 
times  and  will  record  anomalies 

TGI-16-10-16  Redundancy  Management  and  systems  update  will  provide  subsystem 
control,  fault  isolation,  redundancy  management,  switchover  by 
onboard  checkout  and  fault  isolation.  Secure  command  override 
for  burn,  abort  and  alt  mission(s)  cancellation  (single  mode 
word  command(s))  Status  secure  downlinked  for  ground  monitor. 
Secure  command  to  load  memory  module(s)  (i  e , R MGT  , diag- 
nostic T/shootmg  and  overrides). 

Implementation  - The  ground  is  prime  in  monitoring  secure  detailed  Tug  status 
at  all  times  and  has  backup  secure  override  capability 
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TGI-17-10-16  Alternate  mission  determination  and  selection  will  be  by  ground 
option  and  initiated  from  the  ground  by  secure  uplink 

Implementation  - The  ground  will  have  the  capability  of  determining  and  effect- 
ting  an  alternate  Tug  mission  via  a secure  uplink 

TGI-18-10-16  SC  rendezvous  will  be  automatically  accomplished  by  terminal 
phase  guidance  with  the  target  passive  The  ground  will  pro- 
vide event  telemetry  monitoring 


Implementation  - The  ground  is  prime  evaluator  of  detailed  Tug  status  There- 
fore, SC  rendezvous  events  are  telemetered  to  the  ground 


TGI-19-10-16  SC  deployment  monitor,  location,  initialization,  spin-up  and 
release  will  be  performed  automatically  Prior  to  deployment. 
Tug  monitors  go/no  go  SC  status  and  thruputs  SC  telemetry  to 
the  ground  ' 

Implementation  - The  ground  is  prime  evaluator  of  Tug  detailed  status  While 
SC  is  attached  to  the  Tug,  Tug  telemetry  contains  SC  data 


TGI -20-10-16  SC  docking  will  be  accomplished  automatically  with  target  passive 

or  not  actively  evasive  The  ground  will  provide  event  telemetry 
secure  monitoring 


Implementation  - The  ground  is  prime  evaluator  of  Tug  detailed  status  There- 
fore, SC  docking  events  are  telemetered  to  the  ground 


TGI-21-1Q-20  The  Tug  shall  be  capable  of  receiving  secure  commands  from  and 
transmitting  secure  data  to  the  Orbiter  and  Tug/SC  operations 
center(s)  The  Tug  shall  be  capable  of  transmitting  commands 
to  the  Spacecraft  and  receiving  data  from  the  Spacecraft  The 
communications  system  shall  be  Space  Ground  Link  Systems  (SGLS) 
compatible  and  shall  permit  encryption-decryption  capability 


Implementation  - The  Tug  is  capable  of  receiving  secure  commands  from  and 
transmitting  secure  data  to  the  Tug/SC  operations  centers  either  thru  the 
Orbiter  while  attached  or  directly  while  free  flying  The  Tug  forwards  data 
to/from  the  SC  while  they  are  attached  Communications  will  be  SGLS  compatible 
and  have  encryption-decryption  capability 

TGI-22-10-22  The  Tug  shall  be  compatible  with  all  Shuttle  abort  modes  and 
procedure  specified  in  JSC  07700,  Volume  X and  XIV 

Implementation  - The  Tug/Ground  compatibility  with  very  limited  definition  of 
Shuttle  abort  modes  can  not  be  fully  defined 

TGI-24-10-29  The  Tug  shall  provide  the  capability  to  respond  to  backup  or 
corrective  commands  from  the  Orbiter  or  mission  operations  for 
off-nominal  deployment  functions 

Implementation  - The  ground  is  prime  evaluator  of  detailed  Tug  status,  there- 
fore, will  be  aware  of  off -nominal  deployment  functions  The  Tug  will  have 
the  capability  to  respond  to  backup  or  corrective  commands  from  the  TOC 
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TG1-25-10-29  The  Tug  shall  be  capable  of  being  jettisoned  in  orbit  "by 

command  from  Or biter  or  ground  for  emergency  reasons  Pro- 
vide emergency  manual  deploy' of  Tug  as  backup/ 

t i * - 

Implementation  - The  ground  is  prime  evaluator  of  detailed  Tug  status,  there- 
fore, will  be  aware  of  off-nominal  deployment  requirements  1 The" TOC  will 
backup  Orbiter  commanding  of  Tug  jettison  functions  The  Tug  will  have  the 
capability  to  respond  to  backup  or  corrective  commands  for  TOC. 

TGI-33-10-54  No  single  failure  shall  result  in  unprogrammed  motion  of  the 
Tug  while  aboard  the  Orbiter,  during  deployment  within  TBD 
distance  of  the  Orbiter,  or  during  retrieval  of  the  Tug 

Implementation  - The  ground  is  always  backup  to  the  Orbiter  for  safety  critical 
functions,  therefore,  can  not  effect  the  Tug  without  Orbiter  permission  There- 
fore, no  single  point  failure  exists  operationally  at  the  ground/Tug  interface 

* • ^ 

TGI-34-10-60  A capability  for  remotely  controlled  expulsion  of'Tug  main 

propellant  tank  residuals  to  space  before  retrieval  operations 
and  pressurization,  with  inert  gases  be  provided. 

Implementation  - The  Tug  will  automatically  safe  main  propellants,  however, 
the  ground  and  Orbiter  will  backup  the  command  if  required 

TGI-35-10-63  Commands  affecting  safety  critical  equipment  status  must  have 
< associated  data  transmission  to  provide  a positive  functional' 
verification 

Implementation  - Positive  functional  verification  will  be  available  in  the  form 
of  telemetry  response  to  commanded  uplink 

2232  Operational  Requirements  Exceptions 

The  following  are  requirements,  where  there  is  not  agreement  and  exceptions 
are  taken  Rationale  is  given  for  the  exceptions 

• Requirement  from  Baseline  System  Requirements  and  Guidelines, 

Volume  1,  Paragraph  3132 

TGI-5-10-12  Ground  Firing  of  Tug  Main  Engine  - Within  orbit  phasing 

requirements,  and  with  all  systems  enabled  and  prepared,  the 
Tug  acquires  the  proper  vector  and  the  mam  engine  is  fired 
from  the  ground  as  necessary  to  achieve  the1  desired  Spacecraft 
orbit  or  trajectory  insertion  conditions^  (or  retrieval  condi- 
tions for  a retrieve-only  mission) 

! 

Rationale  - The  ground  command  for' mam  engine  burn  is  only  a backup  (contin- 
gency) for  autonomy  Level  II  which  is  baseline  This  is  a normal  function 
performed  by  the  Tug  on-board  computer 

• Requirement  from  Baseline  System  Requirements  and  Guidelines, 

Volume  1,  Paragraph  3 2 6 1 4 ,C  (4)J 
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TGI-6-10-63  Tug  APS  and  Translation  Maneuvers  Disabled  at  Deploy  - Tug 
autonomous  navigation  commands  for  attitude  control  and 
translation  maneuvers  shall  be  disabled  until  a safe  separation 
distance  and  compatible  trajectories  can  be  verified 

Rationale  - Attitude  control  must  be  enabled  immediately  after  deploy  to 
attitude  hold  and  minimize  tip  off  rates 

• Requirements  from  Baseline  System  Requirement  and  Guidelines, 

Volume  1,  Paragraph  3 2 1 1 G. 

TGI— 12— 10-15  Tug  Compatible  with  NASA  STDN/TDRS  and  AF  SGLS/SCF  Communica- 
tions and  Tracking  Systems  - The  baseline  Tug  shall  be 
compatible  with  the  NASA  STDN/TDRS  and  the  AF  SGLS/SCF  communi- 
cations and  tracking  systems 

Rationale  - Tug  system  defined  for  Level  II  Autonomy  has  no  tracking  require- 
ment with  the  addition  of  the  Interferometric  Landmark  Tracker 

a Requirement  from  Baseline  System  Requirements  and  Guidelines, 

Volume  1,  Figure  4 

TGI-13-10-16  Post  Separation  Activation  Sequence  - Automatic  - (After 
secure  RF  uplink  from  ground  to  initiate) 

Rationale  - Tug  activation  is  automatic  for  an  Autonomy  Level  II  Tug  except 
for  contingency 

• Requirements  from  Baseline  System  Requirements  and  Guidelines, 

Volume  1,  Figure  4 

TGI-14-10-16  Orbital  Tracking  - TDRS  and  DSN 

Rationale  - There  is  no  tracking  requirement  for  a Tug  system  designed  for 
Autonomy  Level  II 

a Requirements  from  Baseline  System  Requirements  and  Guidelines, 

Volume  1,  Paragraph  3.2.1  214 

TGI-23-10-28  Deployment,  Ground  Confirmation  of  Mission  Readiness  - After 
physical  separation  from  the  Orbiter,  the  Tug  shall  maintain 
a stable  attitude  consistent  with  Orbiter  deployment  mechanism 
tipoff  rates  until  a safe  Orbiter-Tug  separation  distance  and 
confirmed  mission  readiness  have  been  accomplished 

Rationale  - Consistent  with  Level  II  Autonomy,  the  mission  will  proceed 
automatically  unless  halted  by  ground  intervention  due  to  an  identified 
contingency. 

2233  Operational  Requirements  Deleted 

The  following  9 requirement  numbers  are  those  which  have  been  deleted  from 
further  consideration  because  most  are  operationally  duplicates  or  have  no 
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impact  on  operational  functions  See  Appendix  A Section  3 0 for  require- 
ment statements  and  reasons  for  deletion 

DELETED  REQUIREMENTS  NUMBERS 


TGI-7-10-58  TGI-27-10-45  .TGI-30-10-51 
TGI-8-10-58  TGI-28-10-46  TGI-31-10-54 
TGI-26-10-45  TGI-29-10-51  TGI-32-10-54 


23  SPACE  TUG  ORBITAL  CHECKOUT  REQUIREMENTS  ASSESSMENT  SUMMARY 

This  is  a summary  of  the  Space  Tug  Orbital  checkout  baseline  requirements 
assessment  The  following  paragraphs  contain  results  of  their  assessment  and 
incorporate  action  resulting  from  data  exchange  meetings.  The  requirements 
are  categorized  into  two  ma-in  areas:  Implemented  and  Exceptions.  The 

category  of  Implemented  is  further  divided  or  allocated  to  the  responsible 
operational  element  The  implemented  and  allocated  requirements  are  those 
where  there  is  agreement  and  therefore  are  being  utilized  as  a basis  for 
Space  Tug  orbital  checkout  The  category  of  Exceptions  consists  of  those 
requirements  where  there  is  not  agreement  and  exception  is  being  taken 
Rationale  is  given  for  the  exception. 

231  Operational  Requirements  Implemented  and  Allocated 

The  following  requirements  are  those  where  there  is  agreement  and  therefore 
are  being  implemented  They  are  allocated  as  to  prime  and  back-up  responsi- 
bilities to  enable  specific  definitions  and  sizing  of  operational  impact 

• Shuttle  Prime  Responsibilities 

Shuttle  will  monitor  Tug/ Spacecraft  systems  during  all  flight 
phases  while  in  Cargo  Bay 

Shuttle  will  hold  Tug  APS  inhibited  till  after  release  by 
RMS.  Shuttle  will  enable  TUG  APS 

Shuttle  will  disable  Tug  APS  prior  to  retrieval  or  for  mission 
termination 

Shuttle  will  monitor  TUG/SC  crew  safety  related  parameters 
while  they  are  in  near  vicinity. 

For  Mission  abort,  crew  will  initiate  and  monitor  Tug  pro- 
pellant dump  prior  to  Tug  release. 

Shuttle  will  monitor  Tug/SC  systems  to  ensure  safe  condition 
through  landing 

• Shuttle  Back-up  Responsibilities 

Shuttle  crew  will  support  (upon  ground  request)  pre-deploy  C/0 
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• Ground  Control  Prime  Responsibilities 

Ground  controllers  will  verify  readiness  of  Tug/SC  for  deploy 
based  on  monitoring  Tug/SC  systems. 

Ground  Controllers  will  verify  readiness  of  Tug/SC  for  retrieval 
based  on  monitoring  Tug/SC  systems 

Ground  controllers  will  maintain  detailed  status  of  Tug/SC 
systems  for  entire  mission. 

• Ground  Control  Back-up  Responsibilities 

Ground  control  will  provide  back-up  control  of  crew  safety 
functions. 

• Tug  Prime  Responsibilities 

Redundancy  Management  will  be  done  by  Tug 
Forward  go/no-go  from  SC  C/0  to  TOC 
232  Operational  Requirements  Exceptions 

The  Space  Tug  orbital  checkout  baseline  requirements  were  reviewed  to  determine 
any  potential  requirement  conflicts  with  projected  design  or  operations  philos- 
ophies The  exceptions  are  as  noted  with  rationale  given  for  each 

• Requirement  Excerpt  from  Baseline  Flight  Operations,  Volume  3, 
Paragraph  3 6.1 

Tug/Spacecraft  Monitoring  and  Checkout  by  the  Shuttle 

"The  Shuttle  must  checkout  and  activate  the  Tug  attitude 
hold  systems  prior  to  remote  manipulator  system  (RMS) 
release,  and  inhibit  the  APS  until  after  release  is 
accomplished  11 

Rationale  - APS  will  not  be  checked  out  prior  to  use,  system  consists  of 
series  of  valves  which  will  be  status  monitored  when  used 

• Requirement  Excerpt  from  Baseline  Flight  Operations,  Volume  3, 
Paragraph  4314 

Tug/SC  Deploy 

"They  will  then  remove  the  Tug/SC  from  the  bay  and  deploy 
it  to  the  release  position.  Then  under  control  of  the  crew 
and  monitored  by  the  crew  and  the  ground,  the  Tug  will  be 
prepared  for  release  After  ground  acquisition  of  Tug 
signal,  and  upon  receiving  affirmation  of  correct  configura- 
tion from  the  ground,  the  crew  will  release  the  Tug  and  stow 
the  mampulator(s)  " 
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Rationale  - Ground  acquisition  of  Tug  signal  before  release  from  RMS  will 
not  be  affirmed 

Deploy  lighting,  antenna  pointing  and  Orbiter  interface  constraints  make 
exception  necessary 

2 4 SPACE  TUG  SAFETY  CRITICAL  OPERATIONAL  REQUIREMENTS  ASSESSMENT 

The  Space  Tug  mission  requires  an  unmanned,  powered  stage  be  operating  in  the 
vicinity  of  the  manned  Space  Shuttle  Orbiter  Safety  is  therefore  a prime 
consideration  in  Orbital  Operations  The  following  paragraphs  identify  the 
goals,  the  definitions  used,  the  groundrules  and  the  documentation  reviewed 
Next,  in  Section  2 4 2 is  the  requirements  assessment  summary  In  it  is 
each  of  the'  more  specific  safety  requirements  assessed  along  with  a statement 
of  operational  implementation  Section  243  ends  this  analysis  with  a C&W 
status  measurements  and  annumcators  recommendation. 

2.41  Task  Description 

The  goals  of  this  analysis  are  defined  as  follows. 

% i- 

• To  identify  safety  critical  functions  to  eliminate  or  give  sufficient 
warning,  of  potential  hazard  due  to  failure  of  the  Tug  operational 
system 

• To  assure. proper  consideration  is  given  to  safety  in  mission 
operational  timelines 

• To  assure  proper 'consideration  is  given  to  safety  at  Orbiter/Tug' 
operational  interfaces 

Definitions 


The  definitions  ,used  were 


• vi  Safety  Critical  Functions  - those  which  operationally,  through 

malfunction,  could  be  a hazard  to  people,  property  or  sthe  ecology. 

t Hazard  types  of  most  concern  here  are  burst  caused  by  pressure, 
collision,  .and  electrical  shock  - 

Groundrules 


The  groundrules  used  were 

• Items,  identified  for  C&W  display  are  Safety  Critical  Functions 

• "mpl^ementation  of  hardware,  , software  or  .procedures  required  to 
satisfy  Safety  Requirements  will  not  result  in  a hazardous  condition. 

Documental  on  Reviewed  , 

The  following  documentation  was  used  in  this  assessment 
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• Tug  Baseline  Document  Volumes  1-4,  7/74 

Safety  Requirements 
System  Configuration 

• Payload  Safety  Requirement  for  National  Space  Transportation 
System,  7/74 

t Concurrent  Tug  studies  data  exchange  packages 
Ground  Operations  Study 
Payloads  Study 
Avionic  Study 
Interface  Study 

• IBM  Mission  Modular  Timelines 

2,4  2 TUG  SAFETY  CRITICAL  OPERATIONAL  REQUIREMENTS  ASSESSMENT  SUMMARY 

Many  safety  statements  are  by  necessity  very  broad  As  such,  however,  they 
are  difficult  to  assess  and  report  an  impact  and  show  implementation  The 
more  specific  safety  requirements  which  had  an  impact  on  orbital  operations 
were  therefore  summarized  It  is  possible  to  trace  the  requirements  to  a page 
in  Volume  1 of  the  Tug  Baseline  Requirements  by  using  the  last  two  digits  of 
the  number  of  each  requirement  The  operational  implementation  is  designated 
(01)  Redundant  requirements  are  addressed  only  once 

General 

1- 5  The  proper  functioning  of  the  interface  between  the  STS  and  Tug 

shall  be  maintained  under  all  nominal,  contingency,  and  emergency 
operations  of  either  the  STS  or  the  Tug 

(01)  The  Orbiter/Tug  interface  is  redundant  for  Safety  Critical 
Functions 

2- 51  No  single  Tug  failure  shall  result  in  a hazard  which  jeopardizes 

the  flight  or  ground  crews  of  the  Shuttle,  general  public,  public/ 
private  property  and  the  ecology 

(01)  Potential  failures  creating  hazards  are  precluded  with 
redundant  techniques. 

3- 53  Tug  shall  provide  at  all  times  the  Orbiter  such  information  as 

necessary  concerning  the  status  or  condition  of  Tug  and  Spacecraft 
systems  to  ensure  safety  of  Orbiter  and  crew  Provisions  shall 
also  be  made  for  Orbiter  override  of  safety  critical  Tug  and  Space- 
craft functions  during  stowage  aboard  the  Orbiter  and  during  Tug 
deployment  and  retrieval  phases  of  operations 
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(01)  The  Tug  and  Spacecraft  will  provide  hardwired  C&W  and  safety 
critical  parameters  to  the  Orbiter  while  attached  After  deploy- 
ment and  prior  to  retrieval,  the  C&W  and  safety  critical  parameters 
will  be  provided  to  the  Orbiter  via  an  RF  link 

4- 53  Provisions  shall  be  included  for  control  of  all  safety  critical 

Tug  functions,  including  attitude  and  translational  position 
control  by  Orbiter  crew  during  post-deployment  and  pre-retrieval 
operation  for  Orbiter/Tug  separation  distances  TBD 

(01)  Same  requirement  as  previous  but  expanded  to  requi're  RF 
interface  with  Orbiter  crew  to  allow  limited  Tug  attitude  and 
translational  position  control  of  Tug  during  post-deployment  and 
pre-retrieval  up  to  20  NM  separation 

5- 54  Provisions  shall  be  made  to  confirm  that  all  safety  critical 

Orbiter/Tug  electrical  connections,  fluid  lines,  etc  interfaces 
are  securely  connected 

(01)  Interlock  signals  are  provided  to  the  Orbiter  for  each  inter- 
facing cable  or  fluid  line  ! 

6- 64  No  single  failure  shall  result  m unprogrammed  motion  of  the  Tug 

while  aboard  the  Orbiter,  during  deployment  within  TBD  distance  of 
the  Orbiter,  or  during  retrieval  of  the  Tug 

(01)  Allfcontrols  in  series  with  Tug  motion  will  be  redundant 

t „ 

7- 54  Tug  propellants  and  pressurants  shall  be  reduced  to  a predetermined 

safe  level  prior  to  Tug  retrieval 

(01)  The  Tug  main  propulsion  system  will  be  dumped  and  vented  prior 
to  rendezvous  and  retrieval  by  the  Orbiter 

8- 54  Tug  deploy/ release/ retract  mechanisms  shall  not  cause  a hazard  even 

.after  a failure  has  been  experienced  with  that  system(s) 

(01)  Failure  indications  will  be  issued  for  Tug  deploy/ release/ 
retract  mechanism 

9- 54  Provisions  must  be  made  for  verifying  readiness  of  safety  critical 

Tug  systems  before  total  activation  of  Tug 

(01)  C&W  parameters  will  be  monitored  continuously  by  the  Orbiter 
(and  ground)  All  safety  critical  Tug  parameters  will  be  checked 
and  verified  during  Tug  activation  and  checkout  in  the  Orbiter 

10- 54  Main  propellant  dump  capability  shall  be  available  from  propellant 

servicing  through  the  mission,  including  abort 

(01)  Although  main  propellant  dump  capability  is  available  by 
hardwire  or  uplfnk  during  both  attached  and  detached  modes,  opera- 
tional requirements  will  preclude  dumps  during  certain  periods, 
such  as  deployment  and  retrieval  phases 
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Operational 


11- 58  Propellant  tank  pressures  where  practical  shall  not  be  increased 

to  operational  values  until  TBD  distance  from  the  Orbiter  after 
deployment 

(01)  Tug  main  propulsion  system  will  be  activated  only  when  the 
Orbiter  is  a safe  distance  (TBD)  from  the  Orbiter 

12- 58  Tug  attitude  shall  be  controlled  by  the  Orbiter  immediately  follow- 

ing release  during  deployment  and  before  retrieval  to  preclude 
possibility  of  collision  Control  distance  for  deployment  and 
retrieval  operations  is  TBD 

(01)  Tug  APS  will  be  activated  immediately  after  deployment  and 
deactivated  upon  retrieval  RF  command  capability  will  be  available 
from  deployment  until  retrieval  (when  the  Tug  is  within  20NM  of  the 
Orbiter) 

13- 58  Tug  shall  be  switched  from  command  control  to  internal  attitude  » 

control  after  Orbiter  has  been  sufficiently  moved  (TBD)  so  that  no 
Tug  attitude  change  could  result  in  collision  with  the  Orbiter. 

(01)  Tug  must  receive  release  indication  and  begin  internal  attitude 
control  immediately  either  by  internal  signal  or  RF  commands. 

14- 58  Internal  attitude  control  signal  of  the  Tug  shall  be  capable  of 

being  checked  for  accuracy  by  the  Orbiter  crew  before  release. 

(01)  Tug  internal  attitude  control  signals  will  be  available  at  the 
Aft  Display  and  Orbiter  maneuvers  must  be  made  to  check  accuracy 
of  Tug  subsystem  before  release 

15- 58  Tug  propellant  tank  integrity  shall  be  verified,  pressures  and 

hazardous  fluid  quantities  shall  be  reduced  to  a safe  value,  and 
ordnance  circuits  shall  be  safed  before  Tug  retrieval  operations 
begin 

(01)  The  Tug  main  propellants  will  be  dumped  and  system  deactivated 
prior  to  Orbiter  rendezvous  operations  as  commanded  by  the  Tug  or 
by  the  ground  or  Orbiter  as  B/U  Safety  critical  parameters  will  be 
supplied  by  RF  to  the  Orbiter  during  rendezvous  and  retrieval 
operations 

16- 59  The  Tug  shall  be  visually  inspected  for  docking  readiness  before 

retrieval 

(01)  The  Tug  and  Orbiter  timeline  and  terminal  interval  attitude 
control  system  commands  must  provide  for  visual  inspection  for 
docking  readiness  before  retrieval 
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Mechanical  and  Structural 

17-60  A capability  for  remotely  controlled  expulsion  of  Tug  mam  pro- 
pellant tank  residuals  to  space  before  retrieval  operations  and 
pressurization  with  the  inert  gases  shall  be  provided 

(01)  The  dumping  of  Tug  main  propellant  tank  residuals  can  be 
controlled  via  the  RF  link  (Orbiter  or  ground)  as  a backup-Tug 
onboard  system  is  prime  for  this  function 


Propulsion 

18-62  Interlocks  shall  be  provided  to  assure  that  propulsion  systems  will 
not  be  fired  while  in  the  Orbiter  payload  bay  and  that  no  single 
operation  shall  result  in  propellants  being  dumped  in  the  payload 
bay 

(01)  Interlocks  will  be  provided  at  the  Orbiter  interface  to 
preclude  propulsion  system  firing  or  propellant  dumping  in  the 
payl oad  bay 


Avionics 

19- 63  Message  signals  for  the  Tug  system,  by  hardwire  and  RF  telemetry, 

shall  be  provided  at  the  Shuttle  Data  Management  System  interface 
Measurements  shall  include  Tug  latched/released  indications,  deploy 
mechanism  position  indications,  discrete  pyrotechnic  event  indica- 
tions, sequence  logic  status,  valve  positions,  temperature  and 
pressure  measurements,  and  failure  indications  This  information 
should  also  be  available  prior  to  retrieval 

(01)  Tug  system  caution  and  warning  and  system  status  measurements 
will  be  available  to  the  crew  prior  to  deployment  via  hardwire 
interfaces  and  prior  to  retrieval  via  RF  telemetry 

20- 63  RF  communication  capability  shall  be  available  between  the  Orbiter 

and  the  Tug  for  command  and  control  functions  while  separated  from 
the  Orbiter  and  up  to  a separation  distance  TBD 

(01)  Orbiter/Tug  communications  link  must  be  maintained  for  the 
separation  distance  stated 

21- 63  Tug  critical  command  and  control  circuitry  shall  be  designed  to  be 

fail  operational/fail  safe  as  a minimum 

(01)  The  first  failure  of  Tug  critical  command  and  control  circuitry 
will  not  result  in  any  degradation  of  operational  capability,  it 
will  be  turned  off  by  redundancy  management  The  requirement 
(Fail  Safe)  shall  not  result  in  any  hazardous  function  to  occur  is 
undefined  and  a concern  listed  in  Section  2212  requirement 
0TI-44-10-63 

22- 63  Tug  autonomous  navigation  commands  for  attitude  control  and 

translation  maneuvers  shall  be  disabled  until  a safe  separation 
distance  and  compatible  trajectories  can  be  verified 
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(01)  Tug  autonomous  navigation  will  be  performed  continuously 
throughout  the  mission  The  Tug  attitude  control  system  will  be 
activated  immediately  upon  Orbiter/Tug  separation  and  deactivated 
at  reattachment  The  Tug  attitude  maneuvers  will  be  limited  while 
the  Orbiter  is  within  TBD  distance  of  the  Tug  The  Tug  main  pro- 
pulsion will  be  deactivated  when  the  Tug  is  within  TBD  miles  of  the 
Orbiter 

23- 63  Commands  affecting  safety  critical  equipment  status  must  have 

associated  data  transmission  to  provide  a positive  functional 
verification 

(01)  Whenever  an  Orbiter  command  affects  any  Tug  safety  critical 
equipment,  verification  will  be  sent  back  to  the  Orbiter 

24- 64  The  Tug  electrical  systems  shall  be  designed  with  overload 

protection 

(01)  Overload  protection  must  be  planned  to  isolate  failures  and 
protect  other  circuits 

25- 65  Positive  indications  of  Tug  electrical  systems  shut  down  status 

shall  be  provided  to  the  Orbiter  flight  crew,  prior  to  retrieval 

(01)  The  Tug  requires  the  fuel  cells  until  after  retrieval  The 
communications,  telemetry  and  other  Tug  systems  (DMS,  IMU ) require 
the  fuel  cells  Status  of  the  fuel  cell  will  be  sent  to  the 
Orbiter  however 

26- 65  Tug  shall  have  a means  of  shutting  off  its  electrical  power  under 

emergency  conditions 

(01)  The  electrical  system  design  includes  provisions  for  shutting 
off  electrical  power  under  emergency  conditions 

27- 65  Fuel  cells  are  to  be  activated  only  after  TBD  distance  separation 

from  the  Orbiter 

Tug  fuel  cells  will  be  activated  during  prelaunch  Stop  or  start 
of  the  electrical  power  system  can  be  activated  from  the  Orbiter 
Aft  Station  switch  and  via  the  RF  link  from  either  the  ground  or 
the  Orbiter  Live  fuel  cells,  operating  properly  and  monitored, 
are  not  considered  a safety  hazard 

Spacecraft  Safety  Requirement 

28- 69  No  single  Spacecraft  failure  shall  result  in  a hazard  which  jeo- 

pardizes the  flight  or  ground  crews,  the  general  public,  public/ 
private  property  and  the  ecology  (fail  safe) 

(01)  There  will  be  no  single  point  failure  which  can  jeopardize 
people,  property  or  ecology. 
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29-70 


30-70 


31-70 


32-70 


General 

33- 70 

34- 70 


35-71 


36-71 


Spacecraft  shall  provide  caution  and  warning  data  to  the  Orbiter 
and  crew  for  safety  critical  functions  while  aboard  or  in  the 
near  vicinity  of  the  Orbiter 

(01)  Whenever  the  Spacecraft  is  within  (aboard)  or  in  close  vicinity 
of  the  Orbiter,  the  status  of  safety  critical  Spacecraft  functions 
will  be  available  via  the  Tug  TM  or  hardwired  to  the  Orbiter 

Safety  critical  single  failure  points  shall  utilize  redundant  con- 
trol and  measurement  system 

(01)  There  will  be  at  least  dual  control  and  monitoring  of  all 
Spacecraft  safety  critical  single  point  failure  points. 

No  single  failure  of  the  Spacecraft  shall  result  in  its  unprogrammed 
motion  while  in  the  Orbiter  or  within  TBD  distance  from  the  Orbiter 

(01)  The  Spacecraft  will  be  interlocked,  preventing  any  vehicle 
movement  until  the  Spacecraft  is  a safe  distance  from  the  Orbiter 

Provisions  shall  be  made  to  confirm  that  all  safety  critical 
Spacecraft/Tug  and  Spacecraft/Orbiter  interfaces  are  securely 
connected 

(01)  All  Spacecraft  interfaces  that  could  affect  the  safety  of  the 
Orbiter  will  have  indicators  showing  they  are  securely  connected 
while  in  the  Orbiter  bay  and  prior  to  retrieval  by  the  Orbiter  via 
C&W  panel 


Operations  for  rescuing  an  Orbiter  crew  shall  not  be  hindered  by  a 
Spacecraft  and/or  its  operation 

(01)  Spacecraft  will  not  interfere  with  any  crew  rescue  attempts 

Any  Spacecraft  subsystem  operation  which  impacts  safety  during  the 
launch  and  entry  phases  shall  be  monitored  via  C&W  (caution  and 
warning)  and  controlled  from  the  Orbiter  flight  station 

(01)  The  Orbiter  has  direct  control  and  monitoring  capability  over 
all  Spacecraft  functions  that  could  impact  Orbiter  safety  during 
launch  and  entry  phases. 

Provisions  shall  be  made  for  verifying  critical  Spacecraft  systems 
readiness  before  activation 

(01)  Spacecraft  safety  critical  systems  will  be  verified  ready 
before  total  Spacecraft  activation  by  ground,  Orbiter,  or  Tug 

All  electrical,  mechanical  and  fluid  connections  between  the  Space- 
craft and  Tug  and/or  Orbiter  shall  be  designed  to  be  fail  safe. 
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(01)  No  single  interface  failure  will  cause  an  unsafe 
situation 


Mechanical 

37-72 


Propul  si 
38-74 


39-74 


40-74 


Avionics 

41-75 


42-75 


and  Structural 


A redundant  relief  capability  shall  be  provided  for  Spacecraft 
tanks  which  automatically  limits  the  maximum  pressure  Relief 
shall  be  through  the  Orbiter  vent  system  overboard  Over-pressure 
relief  capacity  shall  be  redundant  to  vent  capacity  {When  vent 
capability  is  provided,  relief  capability  need  not  be  redundant  ) 

(01)  Redundant  means  will  be  provided  to  insure  that  safe  tank 
pressures  are  not  exceeded 


Spacecraft  sequencing  for  attitude  hold  and  mam  engine  starting 
sequence  shall  be  remotely  code  commanded  to  prevent  inadvertent 
operations  of  the  Spacecraft  while  m the  Orbiter  payload  bay  or 
during  the  deployment  phase  of  operation 

(01)  Inadvertant  operation  of  the  Spacecraft  will  be  prevented  by 
use  of  interlocks 

Spacecraft  APS  shall  be  capable  of  being  shut  down  by  one  command 
from  ground  and  Orbiter  control 

(01)  Spacecraft  APS  will  be  capable  of  being  inhibited  from  an 
external  source 

Provisions  shall  be  made  to  verify  completion  of  main  engine 
propulsion  system  safing  prior  to  retrieval 

(01)  Propellant  system  passivation  will  take  place  prior  to 
retrieval  and  will  be  verified  by  the  ground 


Message  signals  from  Spacecraft  systems  shall  be  provided  at  the 
Shuttle  Data  Management  System  interface  Measurements  shall 
include  at  least  Spacecraft  latched/released  indications,  deploy 
mechanism  position  indications,  discrete  pyrotechnic  event  indica- 
tions, sequence  logic  status,  valve  positions,  temperature  and 
pressure  measurements,  and  failure  indications 

(01)  Spacecraft  system  caution  and  warning  and  critical  subsystem 
measurements  will  be  available  to  the  crew  prior  to  deployment  via 
hardwire  interfaces  and  prior  to  retrieval  via  Tug  RF  telemetry 

RF  communication  capability  shall  be  available  between  the  Orbiter 
and  the  Spacecraft  for  safety  related  command  and  control  functions 
while  detached  from  the  Orbiter  and  up  to  a separation  distance 
of  TBD 
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(01)  Orbiter/Tug  communications  link  providing  SC  access  will  be 
maintained  for  the  separation  distance  stated' 

43- 75  Spacecraft  critical  command  and  control  circuitry  shall  be  designed 

to  be  fail -operational /fail  safe  as  a minimum 

(01)  The  first  failure  of  Spacecraft  critical  command  and  control 
circuitry  will  not  result  in  any  degradation  of  operational 
capability  The  requirement  fail  safe  shall  not  result  in  any 
hazardous  function  to  occur  is  undefined 

44- 75  Automatic  event  sequencing  programs  and  automatic  controls  whose 

actuation  could  affect  flight  personnel  safety  shall  be  operative 
by  the  Orbiter,  or  by  ground  control  enabling  switches  (command 
over-ride),  e g , pyrotechnic  sequences,  automatic  deployment 
sequences,,  etc 

(01)  Automatically  activated  software  safety  critical  functions 
will  be  initiated  by  either  the  Orbiter  or  ground  only  when  the 
Orbiter  is  at  a safe  separation  distance  Automatic  activation/ 
deactivation  (or  command)  of  Tug  APS  at  separation/retrieval  is 
required 

45- 75  Commands  affecting  safety  critical  equipment  status  must  have 

associated  data  transmissions  to  provide  a positive  functional 
verification 

(01)  Whenever  an  Orbiter  command  affects  any  Tug  or  SC  safety 
critical  equipment,  a verification  will  be  sent  back  to  the' 
Orbiter 


Electrical 

46-77  Secondary  power  sources  for  safety  critical  functions  shall  be 
provided 

(01)  Redundant  power  will  be  provided  to  safety  critical  functions 

243  C&W  Status  Measurements  and  Annunciators  Recommendation 

The  following  is  the  flight  operational  recommendation  for  status  measurements 
and  C&W  annunciators  resulting  from  Tug  safety  requirements,  subsystem  and 
mission  analysis 
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ANNUNCIATORS 


TUG  SYSTEM  STATUS  TO  C&W 

LH2  Tank  Pressure 
L02  Tank  Pressure 
N^H^  Tank  Temp  1 
NgH^  Tank  Temp  2 
NgH^  Tank  Temp  3 
Fuel  Cell  L02  Pressure 
Fuel  Cell  LH2  Pressure 
Depl  Adapt  Armed 
APS  Armed 

Tug  Mam  Propl  Armed 
Aux  Battery  Temp 
Spacecraft  Depl  Arm  Safe 
Bottle  Press  1 
Bottle  Press  2 
Bottle  Press  3 
Fuel  Cell  Temp  1 
Fuel  Cell  Temp  2 
+28  VDC  Bus 


Mam  Tank  LH2  Press 
Mam  Tank  L02  Press 
N2H^  Tank  Temp 

Fuel  Cell  L02  Press 
Fuel  Cell  LH2  Press 
Depl  Adapt.  Arm  Safe 
Tug  APS  Arm  Safe 
Tug  Mam  Propl  Arm  Safe 
Aux  Battery 
Spacecraft  Arm  Safe 
H£  Bottle  Press 

Fuel  Cell  Temp 


Tug  Critical  Bus  Voltage 


NOTE  This  list  of  C&W  functions  is  the  result  of  coordinated  efforts  to 
date  of  both  GDC  (Interface  Study)  and  IBM  (Orbital  Operations  Study)  but 
does  not  include  Spacecraft1  requirements  of  35  measurements  (maximum)  which 
are  not  identified  by  name 
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2 5 SPACE  TUG  SYSTEMS  OPERATIONAL  REQUIREMENTS  ASSESSMENT 

This  is  a summary  of  the  Space  Tug  Systems  Opera;tionaT^'lnterface'  Requirements 
as  defined  by  the  baseline  documentation  The  following  1 paragraphs  contain  the 
results  of  this  assessment  and  incorporates  actions  resulting  from  data  ex- 
change meetings.  The  requirements  are  categorized  into*  'Implemented,  Deleted, 
Exceptions  and  Proposed  The  category  of  "Implemented"  contains  the  requirements 
upon  which  there,  is  agreement  and  thus  are  being  implemented  In  some  cases, 
however,  there  is  not  a"  total  operational  definition  available  from  companion 
studies  With  each  requirement,  is  a statement  elaborating  on  implementation. 
The  category  of  "Deleted"  consists  of  those  requirements 'removed  because  of 
similarity,  duplication  and  those  not  directly  effecting  the  operational 
interface  The  "Exception"  category  consists  of  those  requirements  where  there 
is  not  agreement  arid  exception  is  being  taken  Rationale  is  given  for  the 
exception.  The  "Proposed"  requirements  category  contains  recommended  re- 
quirements which  became  apparent  during  the  assessment  of  existing  requirements 

2 5 1 Operational  Requirements  Implemented 

The  following  requirements  are  those  where ‘there  is'agreement  and,  therefore, 
are  being  implemented  as  stated; 

TS-1-17-139  Tug  systems  ynll  be  designed  so  that  no  on-board  or  ground 
command  action  will  be  nominally  required  during  Orbiter 
ascent  to  orbit  or  descent  and  landing 

Implementation  - The  Tug  systems  are  planned  so' that  commanding  fromfjthe' 

Orbiter  or  TOC  is  nominally  not  required  during  Orbiter  ascent,  descent  or 
landing 

TS-2-17-3.40,  All  mission  critical  functions  shall  have  redundant  measure- 
, ments  and  redundant  command  capability 

Implementation  - All  Tug  mission  critical  functions  are  planned  to  have 
redundant  measurements  and  command  capability 

s * 

TS-3-17-139  Prior  to  release,  the  Tug/SC  checkout  will  be  accomplished 
from  the  ground 

Implementation  - Tug''and  SC  checkout  will  be  done  primarily  by  onboard  systems 
as  part  of  redundancy  management  of  the  Tug  and  by  the  SC*s  self  checking  , , 
capability.  The  ground,  the  TOC  and  the  SCOC  will  be  prime  evaluator  of  de- 
tailed status  however 

TS-4-17-140  All  mission  critica,!  systems  shall  be  designed  to  fail 
operational  and  all  others  fail  safe 

Implementation  - The  Tug  is  planned  to  be  as  a minimum  dual  redundant 
for  critical  systems  which  means  it  will  be  operational  after  the  first  fail- 
ure however,  meeting  the  fail  safe  requirement  is,  undefined  at  this  time  and 
listed  as  a concern  in  Section  2.2  1 2 requirement  0TI-44-10-63 
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TS-5-17-140  Insofar  as  possible.  Tug  shall  be  designed  to  permit  recovery 
of  the  Tug/SC  in  the  event  of  non-catastrophic  malfunctions 
preventing  a Tug  burn. 

Implementation  - The  Tug  is  planned  to  be  recoverable  if  the  main  propulsion 
fails. 

TS-6-17-140  Provide  emergency  jettisoning  of  Tug/SC  deploying  equipment 
and  antennas  to  complete  retrieval  and  storage  operations  of 
the  Tug/SC 

Implementation  - There  is  no  equipment  on  the  Tug  as  planned  that  requires 
jettison  for  emergency  retrieval  The  engine  bell  must  be  retracted  but 
that  can  not  be  jettisoned. 

TS-7-17-140  Tug  shall  be  designed  to  minimize  lead  time  and  effort  for 

mission  preparation  Specifically,  mission-independent  software 
shall  be  used  insofar  as  possible,  and  software  shall  be  de- 
signed for  ease  of  mission-dependent  changes 

Implementation  - Software  is  planned  to  be  modular 

TS-8-17-140  Systems  management  shall  be  automated  where  feasible  with 
ground  control  backup 

Implementation  - The  Tug  is  planned  to  be  redundant  and  level  II  autonomous, 
therefore,  it  will  contain  onboard  system  management  with  ground  control  as  a 
backup 

TS-9-17-140  Telemetered  measurements  shall  be  provided  for  all  parameters 
which  must  be  maintained  within  critical  limits  or  where  a 
knowledge  of  these  quantities  is  needed  to  determine  the 
operational  status  or  capability  of  a system. 

Implementation  - Tug  critical  system  measurements  are  provided  to  the  Orbiter 
when  within  20  NM  and  all  measurements  are  provided  to  the  TOC  as  continuously 
as  downlink  coverage  permits 

TS-1Q-17-T41  Propellant  dump  capability  shall  be  available 

Implementation  - Propellant  dump  capability  is  available  both  while  in  the 
Orbiter  and  free  flying 

TS-11-17-141  Tug  Support  software  necessary  for  maintenance  and  preparation 
of  mission  flight  software  shall  be  designed  compatible  with 
(TBD)  NASA  computers 

Implementation  - Must  be  stated  TBD. 

TS-12-17-141  All  pressure  vessels  must  have  automatic  relief  capability. 

Implementation  - /'ll  Tun  pressure  vessels  are  pla"np'J  to  have  automatic  relief 
capability 
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TS-13-<17  "141  All  venting  of  the  Tug  shall  be  non-propul  si  ve. 

Implementation  - Tug  venting  is  planned  to  be  nonr-propulsive 

TS-14-17-141  Tug  shall  have  capability  of  isolating  its  electrical  loads 
under  emergency  conditions,  Ground  override  capability  will 
be  available. 

Implementation  - Isolation  will  be  possible  by  redundancy  management  and 
ground  override  as  a conti nguency  is  planned 

TS-15-17-141  Sequence  logic  and  pyrotechnic  firing  circuits  shall  be  at 

least  dual  redundant,  with  ground  control  isolation  capability 

Implementation  - All  Tug  logic  is  planned  to  be  at  least  dual  redundant. 

TS-16-17-141  Safety  design  features  such  as  interlocks,  redundancy, 

grounding,  and  isolation  devices  shall  be  incorporated  so 
that  no  premature  detonation  of  explosive  devices  can  occur. 
Ground  control  override  capability  shall  be  provided. 

Implementation  ^ No  explosive  devices  are  planned  for  Tug, 

TS-17-17-141  The  capability  shall  be  provided  for  the  modification  or 
reload  by  the  ground  of  the  Tug  software. 

Implementation  ^ TOC  as  planned  can  reload  the  Tug  software. 

TS-18-17-85  No  operational  Tug  system  should  constrain  a launch  time  of 
24  hours  after  a launch  scrub 

Implementation  - No  Tug  system  as  planned  will  constrain  a launch  time  of  24 
hours  after  a launch  scrub 

TS-19rl7-88  The  Tug  on-board  prelaunch  targeting  for  planetary  missions 
will  be  pre-loaded  from  the  ground 

Implementation  r The  Tug  on-board  prelaunch  targeting  for  planetary  missions 
are  planned  to  be  pre-loaded  from  the  ground, 

TS -20-17 -95  The  Tug  on aboard  flight  programs  will  be  required  to  perform 

computations  for  four  mission  classes 

(1 } Geosynchronous 

(2)  Low  Earth  Orbit  (near  circular) 

(3)  Low  Earth  Orbit  (elliptical) 

(4)  Planetary 

t 

Implementation  - The  Tug  on-board  flight  programs  are  planned  to  perform 
computations  for  the  four  mission  classes 
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TS-21 -16-92  The  Tug  must  have  the  capability  for  variable  propellant  loads. 

Implementation  - The  Tug  is  planned  to  have  the  capability  for  variable 
propellant  loads 

TS-22-10-58  The  planned  attitudes  of  the  Tug  during  release  and  separation 
from  the  Orbiter  shall  be  such  that  the  attitude  control 
engines  at  no  time  accelerates  the  vehicle  towards  the  Orbiter 

Implementation  - The  mission  planner  will  consider  this,  and  Tug  onboard  GN&C 
will  mechanize  it 

TS-23-10-58  Tug  propellant  tank  integrity  shall  be  verified,  pressures  and 
hazardous  fluid  quantities  shall  be  reduced  to  a safe  value, 
and  ordnance  circuits  shall  be  safed  before  Tug  retrieval 
operations  begin 

Implementation  - The  onboard  program  with  command  safing  and  commands  will 
be  backed  up  by  the  Orbiter  and  the  ground, 

TS-24-10-58  Provisions  shall  be  made  to  pressurize  propellant  tanks  of 
Tug  to  avoid  implosion  during  return  flight. 

Implementation  n The  deployment  adapter  is  planned  to  contain  a HE  bottle 
for  this  purpose  b 

TS-25-10-58  Tug  attitude  control  or  Tug  main  engine  thrust  shall  not  be 
used  for  initial  separation  of  the  Tug  to  a safe  distance 
(TBD)  from  the  Orbiter 

Implementation  - The  Tug  APS  and  MPS  will  not  be  fully  enablecj  until  TBD 
safe  distance  from  the  Orbiter 


TS-27-10-58  Propellant  tank  pressures  where  practical  shall  not  be  in- 
creased to  operational  values  until  TBD  distance  from  the 
Orbiter  after  deployment 

Implementation  - Propellant  tank  pressures  will  not  be  increased  to  operational 
values  until  the  Tug  is  TBD  distance  from  the  Orbiter 


TS-28-1Q-60  A capability  for  remotely  controlled  expulsion  of  Tug  mam 

propellant  tank  residuals  to  space  before  retrieval  operations 
and  pressurization  with  inert  gases  shall  be  provided 


Implementation  - The  Tug  will  automatically  safe  main  propellants,  and 
the  ground  and  Orbiter  will  backup  the  command  if  required 

TS-29-10-15  The  baseline  Tug  shall  be  compatible  with  the  NASA  STDN/TDRS 
and  the  AF  SGLS/SCF  communications  and  tracking  systems 


Implementation  - The  Tug  is  planned  to  be  compatible  with  NASA  STDN/TDRS  and 
AF  SGLS/SCF 
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TS- 31- 10-45 


Alternate  or  redundant  means  of  performing  a critical  function 
shall  be  physically  separated  or  protected  such  than  an  event 
which  causes  the  loss  of  one  means  of  performing  the  function 
will  not  result  in  the  loss  of  alternate  of  redundant  means. 

Implementation  - Redundant  means  of  performing  critical  functions  are  being 
physically  separated  as  a goal 

TS-32-10-16  Attitude  update  will  be  independent 

Implementation  - The  Tug  using  star  trackers,  sun  sensors  and  ILT  is  independent 
for  attitude  update 

TS-33-10-16  Tug  state  determination  will  be  independent,  with  secure  ground 

augmentation  command  as  optional  (passive  beacons  are  permissible) 

Implementation  - The  Tug  using  an  IMU  and  ILT  is  independent  for  state 
determination 

TS-34-10-16  GN&C  will  be  automatic  & independent  (includes  preburn,  burn, 
post  burn  targeting  & reconfiguration)  Use  of  ground-beacon 
acceptable 

Implementation  - GN&C  will  be  automatic  & independent  and  passive  ground 
beacons  will  be  used  with  ILT 

TS-35-10-16  Shuttle  rendezvous  will  be  automatically  accomplished  by  on- 
board computation  of  nav  & guidance,  except  beacon  optional 
for  Shuttle  contact  All  rendezvous  are  to  be  coplanar  with 
Shuttle,  including  abort. 

Implementation-  - Tug  rendezvous  with  the  Shuttle  is  planned  to  be  automatic, 
with  the  Tug  moving  to  a rendezvous  box,  then  attitude  holding  until  the 
Shuttle  moves  in  and  captures  the  Tug. 

TS-36-10- 16  SC  docking  will  be  accomplished  automatically  with  target 
passive  or  not  actively  evasive  Event  telemetry  will  be 
with  secure  monitoring 

Implementation  - SC  docking  is  planned  to  take  place  automatically  after  a 
visual  inspection  via  TV  The  events  will  be  telemetered  with  secure  monitoring 

TS-37-10-16  SC  rendezvous  will  be  automatically  accomplished  by  terminal 
phase  guidance  with  target  passive  Event  telemetry  will  be 
with  secure  monitoring 

Implementation  - SC  rendezvous  is  planned  to  take  place  automatically  The 
events  will  be  telemetered  with  secure  monitoring 

TS-38-10-19  The  baseline  Tug  while  in  the  payload  bay  shall  provide  systems 
status  data  to  and  receive  commands  from,  Tug/SC  Operations 
Center(s)  via  the  Orbiter  provided  communications  relay  as 
defined  in  JSC  07700 

Implementation  - The  Tug  is  planned  to  provide  systems  status  data  to  and 
receive  commands  from  TOC/SCOC  via  the  Orbiter  while  onboard’ 
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TS-4G-10-S4  Safety  critical  control  circuits  shall  be  capable  of  .being 
verified, 

\ 

Implementation  - Safe  critical  circuits  are  planned  to  be  capable  of  verifi- 
cation 


252  Operational  Requirements  Exceptions 

The  following  is  a requirement  where  there  is  not  agreement  and  exception  is 
taken  Rationale  is  given  for  the  exception 

• Requirement  from  Baseline  System  Requirements  and  Guidelines,  Vol 
1 , Paragraph  3 2 6 1 4 d (20} 

TS-44-1Q-65  Fuel  cells  are  to  be  activated  only  after  TBD  distance 
separation  from  the  Orbiter 

Rationale  - Tug  fuel  cells  will  be  activated  during  prelaunch  Stop  or 
start  of  the  electrical  power  system  can  be  activated  from  the  Orbiter  Aft 
Station  switch  and  via  the  RF  link  from  either  the  ground  or  the  Orbiter 
Live  fuel  cells,  operating  properly  and  monitored,  are  not  considered  a 
safety  hazard 


2,53  Operational  Requirements  Deleted 


The  following  12  requirement  numbers  have  been  deleted  from  further  considera- 
tion because  most  are  operationally  duplicates  or  have  no  impact  on  operational 
functions  See  Appendix  A Section  4,0  for  requirement  statements  and  reasons 
for  deletion. 


TS-26-10-58 
TS-30-1Q-46 
TS-39-1Q-28 
TS-41 -10-65 


DELETED  REQUIREMENTS  NUMBERS 
TS-42-10-65 
TS-43-10-65 
TS -45-10 -75 
TS-46-10-66 


TS-47-10-66 
TS -48 -10 -66 
TS-49-10-66 
TS-50-10-66 


254  Space  Tug  Systems  Operational  Requirements  Proposed 

The  following  requirements  have  been  identified  from  the  analysis  of  the  Space  Tug 
Systems  operations  and  are  proposed  to  be  added  to  the  baseline 

1 Maintain  LO?  & LhL  to  run  fuel  cells  for  4-5  hours  following 
propellant  ^dumps^ 

The  fuel  cells  are  required  to  power  the  communication,  telemetry, 

IMU  and  DMS  until  after  Tug  recovery  by  the  Orbiter 

2 Autonomous  Navigation  requires  ILT  or  equivalent 

Autonomous  navigation  is  cost  effective  because  it  is  independent 
of  ground  support  costs  ILT  is  proven  to  be  the  most  accurate 
means  of  navigation  update 
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3 Rendezvous  & Docking  Sensor  Range  (75-100  NM)  minimum  0 TPI 
This  requirements  results  in  minimum  expenditure  of  APS  fuel 

4 Fuel  cells  activated  during  prelaunch  to  supply  tug  power  through 
ascent  and  on-orbit  operations 

The  Tug  power  requirements  exceed  that  available  from  the  Orbiter 
and  therefore  require  full  Tug  mission  duration  use  of  its  fuel 
cells. 

5 Telemetry  from  Tug  to  Orbiter  and  Tug  to  ground  must  be  the  same 

This  will  allow  one  set  of  software  to  be  used  to  encode  and  decode 
the  telemetry  for  the  various  types  of  processing  that  will  be 
required 

6 Uplink  (command)  formats  from  ground  thru  Orbiter  to  Tug  and  from 
Ground  to  Tug  must  be  the  same 

This  will  allow  use  of  one  set  of  software  and  or  hardware  encoders 
and  decoders  on  the  ground  and  onboard  the  Orbiter  and  the  Tug 

7 Orbiter  to  Tug  RF  must  be  established  prior  to  umbilical  disconnect 

This  is  required  to  assure  the  safety  of  the  Orbiter  and  it's  ability 
to  control  the  Tug  once  it  is  free  flying 

J 

8 Design  Goal  <-  IUS  and  Tug,  telemetry  and  command  formats  should  be 
the  same  or  similar 

This  is  required  to  allow  ease  of  transition  i e,  personnel  training, 
reuse  of  some  procedures,  reuse  of  software  and  or  hardware  encoders 
and  decoders  on  the  ground  and  onboard  the  Orbiter,  the  IUS  and  the 
Tug 

9 360°  Antenna  Radiation  for  both  telemetry  and  command 

This  is  required  for  safety  to  allow  minimum  attitude  constraint 
between  Tug  and  the  Orbiter  (whose  violation  will  result  in 
communication  drop  outs)  while  the  Tug  is  operating  close  to,  and 
is  a hazard  to,  the  Orbiter 

10  On-orbit  target  update  capability  is  required 

As  part  of  contingency  planning,  to  accommodate  a variety  of 
partly  failed  hardware  situations,  it  will  be  necessary  to  do  a target 
update  on-orbit 
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SPACE  TUG  MISSION  OPERATIONS  ANALYSIS 


The  Space  Tug  missions  consist  of  delivery  to  and/or  retrieval  of  Spacecraft 
from  orbits  outside  the  performance  range,  of  the  Shuttle  Orbiter  Missions  are 
currently  planned  in  the  following  Spacecraft  disciplines  Astronomy;  High 
Energy  and  Solar  Physics,  Atmospheric  Physics,  Earth  Observation,  Communication 
and  Navigation,  and  Planetary  Mission  sources  include  NASA,  DoD,  commercial 
and  foreign  users. 

This  section  presents  typical  sets  of  Space  Tug  missions  which  were  analyzed  to 
determine  operational  requirements 

Three  typical  mission  models  were  utilized  during  the  study  for  the  years 
1984-1991  These  models  contained  representative  payload  (SC)  classes,  f_Ti.ght 
frequency,  and  estimated  payload  weights  and  dimensions  They  were  grouped*’.! 
according  to  their  destination  (1)  Sun  Synchronous,  (2)  Geosynchronous,  and 
(3)  Interplanetary  The  three  mission  models  used  in  this  study  were,  (!) 

Spa'ce  Shuttle  Traffic  Model,  October  1973,  (2)  the  DoD  Traffic  Model  and  (3) 
a' summary  traffic  model  developed  by  the  NASA  Tug  task  team  during  the  course 
of^the  study  Figure  3 0 0-1  shows  the  mission  type,  anticipated  launch  schedule, 
maintenance  time  and  mission  planning,  training, and^simulation  intervals  for  1984 
The  year  1984  launch  density  was 1 extracted  from  the  mission  model  to  determine 
overlaps  in  missions  -As  can  be  seen,  there  is  no  overlap  of  Space  Tug  missions, 
therefore,  sizing  estimates  for  the  study  are  based  on  single  mission  requirements. 
It  should  be  kept  in  mind  that  these  data  are  only  representative  of  what  should 
be'expected  In  particular,  planning  and  operational  analyses  should  investi- 
gate the  impact  of  variations  in  the  relative  frequency  of  the  various  classes, 
changes  in  the  Spacecraft  characteristics,  and  other  factors  that  may  change  and 
are  a part  of  operational  planning 

3 1 REFERENCE  MISSION  DESCRIPTIONS 

The  following  paragraphs  describe  the  types  of  reference  missions  evaluated 
during  the  study  To  enable  the  identification  of  operational  requirements  from 
the  many  diverse  missions,  the  individual  missions  were  grouped  into  three  major 
classes  and  analysis  performed  on  each  class*  The  three  classes  used  were,  (1) 
Geosynchronous  Missions,  (2)  Sun  Synchronous  Missions,  and  (3)  Interplanetary 
Missions  Characteristics  of  these  mission  classes  are  discussed  m the  follow- 
ing paragraphs 

•*3  1 1 Geosynchronous  Missions 

Several  types  of  Geosynchronous  Missions  are  defined  in  the  current  traffic 
models  These  missions  can  be  grouped  into,  (1)  deploy  only,  (2)  retrieval 
only,  (3)  deploy  one  Spacecraft  and  retrieve  one  Spacecraft,  and  (4)  deploy 
two  Spacecrafts  and" retn eve  one  Spacecraft  The  mission  sequence  for  the 
deployment  of  two  Spacecrafts  and  retrieval  of  one  is  presented  in  Table  >0^ 

3 1 1-1  In  this  case,  it  was  assumed  that  the  Spacecrafts  were  located  60 
apart  -(longitude) 
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SCHEDULE  11984  TUG  SCHEDULE  -FIRST  SIX  MONTHS 
ITEMS  JANUARY  FEBRUARY  MARCH 


LAUNCH 

SCHEDULE 


APRIL 


MAY 


JUNE 


6 6 21  23  6 8 24  26 


14  21  | 4 7 20  24  K 0 23  27 


PERIODIC 
MAINTENANCE 
(THREE  DAYS 
EVERY  QTR  ) 


ION 
PLANNING, 
TRAINING, 
AND 

SIMULATION 

AVAILABILITY 


SCHEDULE  [1984  TUG  SCHEDULE  -LAST  SIX  MONTHS 

ITEMS  JULY  I AUGUST  1 SEPTEMBER  I OCTOBER  I NOVEMBER  1 DECEMBER 


LAUNCH 

SCHEDULE 


12  17 


□ 18  21 

I 


15  22 


15  22 


• 16 


DOWfJTl|,MF,CE  11  18  2 9 * 23  3C  15  22  7 11  26  30  15  22  » 16 

I I I I I I I I II  II  I I II 

A MISSION) 11  11  11 1 1 11  11 1 1 

PERIODIC  1517  28  x 

MAINTENANCE  ■ ■ 

(THREE  DAYS  ■ ■ 

EVERY  QTR ) ■ 

PLANNING,  l1  18 18  l1  10  14  18  22  81  ™ 28  6 12  26  31  14  23  27  | g l7  3l| 

training,  h ■■  a ■ mm  wm  m m ■■  mm 

simulation  ■■■  ■■  wM  .wrNWr 

AVAILABILITY  I 


Figure  3 0 0-1  1984  Space  Tug  Launch  Schedule 
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Table  311-1  Mission  Sequence  for  a Dual  Deployment,  Single 
Retrieval  Geosynchronous  Mission 


EVENT 

INITIAL 
WT  (lbs) 

APS 

(tbs) 

INERTS 

LOSSES 

EVENT 

DURATION 

(Hrs) 

TOTAL 

TIME 

(Hrs) 

a V 
(F/S) 

1 

Tug  Separation  from  OrbLter 

58  855 

8 6 

10  0 

2 0 

2 0 

2 

Phase  in  Shuttle  Orbit 

58  836 

21  4 

46  0 , 

11  0 

13  0 

3 

Burn  into  Phasing  Orbit  , 

(Full  thrust) 

58  769 

” 

" 

0 13 

13  13 

4494 

4 

Coast  in  Phasing  Orbit,  One 
Revolution 

43, 271 

17  5 

5 0 

3 0 

16  13 

5 

Imect  into  Geosynchronous 
Transfer  (Tank  head  idle  + 
full  thrust) 

43  248 

1 1 

16  24 

3672 

6 

Coast  to  Midcourse  Correction 

33  678 

13  8 

6 0 

1 5 

17  74 

7 

Midcourse  Correction  (Tank  head 
idle  +■  pump  idle) 

33, 658 

03 

17  77 

50 

8 

9 

Coast  to  Geosynchronous 

Circularize  at  Geosynchronous 
(Tank  head  idle  + full  thrust) 

33  536 
33,  506 

14  0 

16  0 

3 96 
12 

21  73 
21  85 

5826 

10 

Coast  and  Orbit  Trim 

22  529 

102  7 

56 

12  0 

33  85 

11 

Deploy  First  SC  (1, 000  lbs) 

22, 370 

31  5 

- 

1 0 

34  85 

12 

Inject  into  Phasing  Orbit  (Tank 
head  idle  + pump  idle) 

21  338 

- 

05 

34  90 

480 

13 

Coast  in  Phasing  Orbit 

20  623 

13  7 

105 

28  0 

62  90 

14 

Circularize  at  Geosynchronous 
(Tank  head  idle  + pump  idle) 

20  504 

- 

05 

62  95 

480 

15 

Deploy  Second  SC  (1,  000  lbs) 

19, 816 

37  7 

6 

1 0 

63  95 

16 

Inject  into  Phasing  Orbit  (Tank 
head  idle  + pump  idle) 

18,  772 

" 

04 

63  09 

258 

17 

Coast  1 5 Revolutions  in  Phasing 
Orbit 

18,426 

14  7 

146 

39  0 

102  99 

Table  3. 1. 1-1  Mission  Sequence  for  a Dual  Deployment,  Single 
Retrieval  Geosynchronous  Mission  (Continued) 


EVENT 

INITIAL 
WT  (Iba) 

APS 

(lbs) 

INERTS 

LOSSES 

EVENT 

DURATION 

(hra) 

TOTAL 

TIME 

(hra) 

A V 
(F/S) 

18 

Height  Adjustment  Burn 
(Tank  head  idle) 

18,266 

- 

- 

01 

103  00 

10 

IQ 

Coast  in  Adjusted  Phasing  Orbit 

18, 251 

11  1 

49 

13  0 

116  00 

20 

Phasing  Orbit  Circularization 
(Tank  head  idle  + pump  idle) 

18, 191 

- 

04 

116  04 

258 

21 

SC  Rendezvous  and  Retrieval 
(1200  lbs) 

17,856 

96.5 

IS 

4 0 

120  04 

22 

Phase  at  Geosynchronous  for 
Nodal  Crossing 

18,944 

11  2 

45 

12  0 

132  04 

23 

DeboostBurn  (Tank  head  idle 
*■  full  thrust) 

18,888 

- 

- 

.08 

132  12 

5840 

24 

Coast  to  Midcourse  Correction 

12, 686 

7.5 

6 

1 0 

133  12 

25 

Midcourse  Correction  (Tank 
head  idle) 

12,673 

- 

- 

01 

133. 13 

13 

26 

Coast  to  170  n mi.  Perigee 

12,659 

8.1 

24 

4.2 

137  33 

27 

Inject  into  Return  Phaping  (Tank 
head  idle  + full  thrust) 

12,627 

05 

137  38 

3791 

28 

Coast  1 Revolution  in  phasing 

9.751 

7.8 

18 

3.0 

140  38 

29 

Circularize  at  170  n mi  (Tank 
head  idle  4-  full  thrust) 

9,  725 

05 

140  43 

42  43 

30 

Rendezvous  with  Shuttle 
(SC  - 1200  lbs  propellant 
reserve  - 276  lbs) 

7.  280 

32.4 

4.  0 

144  43 

As  the  evaluationof  geosynchronous  missions  (Figure  31  1-1)  progressed,  it 
was  determined  that  missions  could  be  represented  by  a standard  set  of  building 
blocks  where  each  block  (or  module)  contained  those  operational  functions  (or 
tasks)  required  for  mission  completion  Once  these  buildings  blocks  were 
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defined,  they  could  be  interleaved  to  represent  specific  missions.  Paragraph 
3 2 describes  this  modular  approach  and  contains  the  functions  within  each 
standard  module 

As  an  example.  Figure  3 1.1-2  depicts  the  standard  modules  designed  to  re- 
present a single  placement,  single  retrieval  geosynchronous  mission. 

3 12  Sun  Synchronous  Missions 

The  Sun  Synchronous  mission  class  assumes  a Space  Tug  deployment  in  low-earth 
orbit  («205  NM)  by  the  Orbiter  and  a transfer  below  and  behind  a Spacecraft  in 
a 900  NM  circular  orbit.  After  orbital  trims  and  the  terminal  rendezvous 
sequence  has  been  completed,  the  Tug  deploys  a Spacecraft  and  retrieves  another. 
The  Tug  then  executes  the  two  burn  maneuver  to  place  the  Tug  in  a 215  NM  orbit 
ahead  of  the  Orbiter  The  geometry  for  this  mission  class  is  defined  by 
Figure  3 1 2-1 

As  in  the  Geosynchronous  Mission  class,  the  standard  operational  modules  were 
interleaved  to  represent  the  Sun  Synchronous  missions.  Figure  3 1 2-2  depicts 
a Sun  Synchronous  mission  for  a single  placement,  single  retrieval  case 

3 1 3 Interplanetary  Missions 

> 

There  is  little  doubt  that  the  Space  Tug  can  satisfy  the  requirements  of  most 
of  the  Geosynchronous  and  Sun  Synchronous  missions.  However,  planetary  missions 
are  unique  in  that  the  delta-velocity  requirements  are  high  and  this  mission 
class  has  not  received  the  depth  of  analysis  of  other  classes. 

The  flight  profile  selected  for  the  Space  Tug  planetary  mission  class  is 
illustrated  by  Figure  3 1 3-1  The  first  maneuver  required  of  the  Tug  after 
deployment  and  checkout  is  an  elliptical  transfer  maneuver  which  is  designed  to 
break  the  Tug  partial  escape  maneuver  into  two  maneuvers  to  reduce  the  gravity 
losses  The  second  Tug  maneuver  places  the  vehicle  on  a partial  escape  come. 

The  Spacecraft  then  separates  and  the  kick  stage  (if  required)  supplies  the 
additional  delta-velocity  needed  to  place  the  SC  on  the  desired  escape  conic 
The  third  Tug  maneuver  occurs  after  sufficient  time  has  elapsed  after  maneuver 
two  to  permit  a turn-around  into  a retro  firing  position  and  places  the  Tug  on 
an  elliptical  trajectory  with  the  perigee  radius  in  the  vicinity  of  the  desired 
Tug  return  orbit  Maneuvers  three,  four  and  five  will  require  plane  changes  to 
compensate  for  the  nodal  regression  rate  differences  between  the  Orbiter  and 
the  Tug  The  fourth  Tug  maneuver  places  the  Tug  into  an  elliptical  phasing 
orbit  and  maneuver  five  is  designed  to  circularize  the  Tug  into  an  orbit  above, 
ahead,  in-phase  and  in-plane  with  the  Orbiter  Maneuver  four  is  added  to  give 
the  Tug  the  additional  flexibility  to  compensate  for  navigation  errors  and 
maneuver  execution  errors  that  would  potentially  place  the  Tug  outside  of  the 
Orbiter  retrieval  box  capability 

The  targeting  requirements  for  using  the  Space  Tug  in  a planetary  mission  are 
complex  and  will  require  a sophisticated  prelaunch  targeting  program  to  optimize 
the  Tug  propellant  loading  when  given  a Spacecraft  description  and  turn  around 
time  constraints  for  the  Tug  return  phase.  The  complexity  of  this  mission  makes 
it  desirable  to  baseline  a day-to-day  launch  on  time  (no  daily  launch  window). 
Prelaunch  targeting  shall  determine  the  launch  time  and  Orbiter  orbital  insertion 
targeting  parameters  (taken  from  the  Space  Shuttle  data  bank)  necessary  for 
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MISSION  MODULE  SEQUENCE  FOR  GEOSYNCHRONOUS  SPACECRAFT  DELIVERY  TUG  MISSION  (SINGLE  PAYLOAD 
PLACEMENT) 


Figure  311-2  Mission  Module  Sequence  for  Geosynchronous  Spacecraft  Delivery  Tug  Mission  (Single  Payload  Placement) 
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Figure  3 1 3-1  Space  Tug  Planetary  Transfer/Return  Profile 
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Space  Tug  deployment,  the  on-orbit  targeting  parameters  for  Tug  maneuvers  one 
through  five,  and  the  phase  adjustment  targeting  parameters  to  compensate  for 
off-nominal  Orbiter/Tug  phasing  conditions  at  ignition  of  maneuver  four  The 
guidance  presettings  can  be  derived  from  the  targeting  parameters  The  Tug  on- 
board targeting  for  planetary  missions  is  baselined  to  be  pre-loaded  from  the 
ground  The  mission  shall  require  a dedicated  Orbiter  in  the  sense  that  no 
unplanned  maneuvers  (prior  to  launch)  shall  be  made  which  will  destroy  the 
original  Orbiter  ephemeris  after  Tug/kick-stage/SC  deployment 

As  m the  other  mission  classes,  standard  operational  modules  were  interleaved 
to  represent  the  interplanetary  mission  Figure  3 1 3-2  depicts  an  inter- 
planetary Space  Tug  mission-for  a single  placement  case 

3 2 MISSION  MODULE  TIMELINES 

Prior  Space  Tug  studies  have  revealed  that  mission  event  sequences  (timelines) 
can  be  modularized  (subdivided  into  the  longest  consecutive  sequence  of  events 
which  occur  in  the  same  order  for  a particular  function)  The  modularization 
of  mission  event  sequences  Is  a common  technique  used  in  most  airborne  flight 
programs  to  segregate  similar  computer  functions  This  technique  simplifies 
maintenance  of  the  program  by  limiting  the  effect  of  changes  to  smaller  areas 
of  consideration  and  facilitates  the  calling  of  functions  when  a particular 
action  is  required 

3 2 1 Principles  of  Mission  Modularization 

The  development  of  the  NASA  Space  Tug  mission  modules  (timelines)  evolved  from 
work  from  prior  Tug  studies,  concurrent  analysis,  and  past  experience  The 
first  step  in  the  process  was  to  identify  the  major  functions  common  to  any 
possible  Tug  mission  The  major  functions  for  Tug  mission  were  found  to  be 
Orbiter  launch  operations,  on  orbit  coast.  Tug  mainstage  burn.  Tug  trimburn, 
payload  placement,  payload  rendezvous,  payload  docking,  payload  retrieval, 
payload  service,  Orbiter  retrieval,  and  abort 

With  these  major  functions  it  is  possible  to  construct  a sequence  of  operations 
which  satisfy  the  total  mission  spectrum  These  functions  also  accommodate  the 
unplanned  situations  which  the  Tug  is  expected  to  handle  Deviations  to  the 
nominal  mission  sequence  will  result  in  entry  to  one  of  these  modules 

After  the  identification  o"f  the  major  mission  functions,  the  sub-functional 
sequence  within  each  module  was  established  Flow  charts  are  included  with 
each  mission  module  timeline  to  visually  depict  the  major  functions  within  each 
module  The  Orbiter,  Crew,  Tug,  and  Tug  Operations  Center  (TOC)  activities 
associated  with  each  sub-function  were  constructed,  sequenced,  and  timed 
These  activities  are  the  events  listed  in  each  timeline 

The  identification  of  each  event  has  been  accomplished  by  assigning  a two  digit 
number  to  represent  the  event  position  in  the  module  sub-function  sequence 
This  is  the  number  immediately  to  the  right  in  the  identification  number  column 
of  the  time  line  tables  The  next  two  digits  represent  the  general  sequence 
of  sub-functions  within  the  module  Some  sub-functions,  like  some  events,  are 
not  necessarily  sequential  The  third  double  set  of  digits  are  the  module 
identification  number  It  is  possible  to  extend  the  modules  into  a next 
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MISSION  MODULE  SEQUENCE  FOR  INTERPLANETARY  TUG  MISSION 


(SINGLE  PAYLOAD  PLACEMENT) 


numbering  level  which  would  then  be  module  groupings  for  a particular  mission 
The  positive  identification  of  events  also  permits  the  tracing  and  quantifying 
of  events  for  analytical  purposes 

Duration  times  for  sub-functions  and  associated  events  appear  both  in  hours  and 
minutes  These  times  are  tabulated  in  columns  opposite  the  identification 
number  followed  by  a mission  reference  time  which  is  related  to  a key  event  withir 
the  module  Key  events  are  those  events  which  commit  the  mission  to  a new  phase 
Bar  charts  to  the  extreme  right  have  been  created  to  provide  a picture  of  event 
time  duration  and  sequence  relative  to  the -total  module  activity  Times  for 
many  events  represent  best  estimates  and  are  subject  to  change  as  refinements 
in  mission  definition,  vehicle  and  ground  systems  continue  * 

322  Mission  Modules 

The  mission  modules  addressed  in  this  section  are 

1 Orbiter  Launch  Operations 

2 On  Orbit  Coast 

3 Mainstage 

4 Trimburn 

5,  Payload  Placement 

6 Rendezvous 

7 Docking 

& Payload  Retrieval 

9 Service 

10  Orbiter  Retrieval 

11  Abort 

3221  Orbiter  Launch  Operations 

The  Orbiter  Launch  Operations  function  is  composed  of  a sub-set  of  eight 
sequential  sub-functions  which  are  entered  from  the  launch  preparation  phase 
T-3  hours  and  terminated  with  the  Tug  In  low  earth  orbit,  checked  out,  and 
waiting  convergence  of  its  targeting  equations  for  first  engine  burn  Figure 
3 2 2-1  is  a flow  diagram  illustrating  the  sub-functional  sequence  within  the 
module  Table  322-1  is  the  major  Tug,  Orbiter,  and  TOC  events  occurring 
during  a nominal  Orbiter  Launch  Operations  module 

32211  Prelaunch  Operations 

During  the  prelaunch  operations  from  T-3  hours  till  liftoff  the  final  prepara- 
tions for  boost  to  orbit  will  be  made  The  Orbiter  crew  will  ingress  and  begin 
monitoring  Tug  Caution  and  Warning  parameters  They  will  also  support  prelaunch 
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Figure  3.22- 1 Standard  Orb  iter  Launch  Operations  Module 


Table  3 2 21  Standard  Orb  iter  Launch  Operations  Module 
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Table  322-1  Standard  Orb  iter  Launch  Operations  Module  (Continued) 


STANDARD  ORB  ITER  LAUNCH  OPERATIONS  MODULE  (01)  (CONTINUED) 


EVENT  DESCRIPTION 

EVENT  HUMBER 

EVENT 

DURATION 

(HOURS) 

EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 

DEPLOY  TUG 

OS  00 

00  333 

- 0 267 

ELECTRICAL  POWER  TRANSFER 

05  01 

00  017 

- 0 267 

FLUID  AND  PAYLOAD  UMBILICALS 

05  02 

00  017 

- 0 250 

RETRACTION 

FORWARD  LATCHES  RELEASED 

05  03 

00  017 

- 0 233 

ROTATION  TO  REMOVAL  POSITION 

05  04 

00  050 

- o 217 

RMS /TUG  ATTACHMENT 

05  05 

00  017 

- 0 167 

TUG/0R1ITER  RF  TM/CMD  LINK  ESTA- 

05  06 

00  €50 

- 0 150 

BUSHED  AND  VERIFIED 

TUG/DA  SEPARATION 

05  07 

00  000 

TUG  REMOVAL  BY  RMS 

05  08 

00  083 

- 0 100 

APS  ASM  (HARDWARE  ENABLES,  SOFTWARE 

05  09 

00  017 

- 0 017 

INHIBITED) 

HMS/TUG  SEPARATION 

05  10 

00  017 

REF 

TUG  APS  ACTIVE  (ATTITUDE  HOLD) 

05  11 

ORBITER  EVASIVE  MANEUVER 

05  12 

TUG/GROUND  RF  TM/CMD  LINK 

05  13 

00  050 

0 067 

ESTABLISHED  AND  VERIFIED 

TUG  CONTROL  HANDOVER  TO  GROUND 

05  14 

00  017 

0 083 

ENABLE  TUG  SYSTEMS 

06  00 

00  167 

0 100 

ISSUE  ENABLE/ ACTIVATION  SEQUENCE 

06  01 

00  017 

0 100 

COMMAND 

ACCEPT  ENABLE  SEQUENCE  COMMAND 

06  02 

00  017 

0 117 

INITIATE  ATTITUDE  MANEUVER  CAPABILIT 

06  03 

00  017 

0 133 

EXTEND  MAIN  ENGINE  NOZZLE 

06  04 

00  OSO 

0 150 

ACTIVATE  MAIN  PROPULSION  SYSTEM 

06  05 

00  050 

0 200 

CHECK  AND  VERIFY  TUG  SYSTEMS 

07  00 

0 200 

0 250 

CONDUCT  FULL  SCALE  CHECKOUT 

07  01 

00  200 

0 250 

MONITOR  SYSTEMS  PERFORMANCE 

07  02 

00  200 

0 250 

MISSION  ENABLE 

08  00 

OD  017. 

0 450 

COMMAND  MISSION  ENABLE 

08  01 

00  017 

0 450 

MONITOR  SEQUENCE 

08  02 

00  017 

0 450 

EVENT 
START 
TIME  IN 
MISSION 
(HOURS) 


Event  time  in  minutes 
RefererweTime 
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Tug  checkout  where  required*  The  Tug  vehicle  will  be  cycled  through  final s 
preflight  checks  including  simulated  flight,  command,  and  telemetry  checks 
Target  update  will  be  permitted  late  in"  the  countdown  if  required.  The  Tug 
electrical  power  will  be  transferred  to  the  Tug  fuel  cell  power  system  prior  to 
liftoff  to  assist  the  Orbiter  with  the  extensive  boost  to  orbit  power  require- 
ments 

32212  Orbiter  Launch  (Liftoff) 

t 

During  thej  boost  to(  orbit -by  the*  Orbiter,  both  the  Orbiter  crew  and  the  Tug 
Ground  Control  Center  monitor 'the  safety  critical  Tug  Caution  and  Warning 
parameters  The  nominal  function  of  the  Tug  during  this  time  period  will  be  to 
supply  its  own  electrical  power  and  maintain  a safe  state  Maintaining  a safe 
state  will  include  the  venting  of  propellants  to  maintain  proper  tank  pressures 

32213  Phasing  Coast 

Dunng*'phasing  coast  and  circularizations  maneuvers,  the  TUg,  will  be  maintained 
in  the'“same  state  as  boost  However,  it  is  "possible' and  likely  that  Tug  pref- 
deployment  actvities  will  commence  dumg  this  period 

32214  Pre-deployment  Checkout 

The  pre-deployment  checkout  of  the  Tug  will  be  initiated  approximately  16  minutes 
prior  to  the  start-of  the  actual  deployment  sequence-  During  this- time  the 
Orbiter  will  be  maneuvered  to  the  appropriate  deployment  attitude  and  the  payload 
bay  doors  will  be  opened  The  Orbiter  systems  necessary  for  deployment  will  be 
activated  and  readied  for  the  deployment  operation 

During  this  period,  the  Tug  IMU  will  be  initialized  and  Tug/Orbiter  navigation 
compared  If  an  attitude  and/or  navigation  update -is  required  at  this  time  it  can 
be  issued  to  the  Tug  via  the  Orbiter  Ground  control  personnel  will .evaluate 
Tug  data  telemetered  via  Orbiter  telemetry  and  ascertain  if  Tug  functions  are 
nominal  and  the  Tug  is  ready  for  deployment  The  Orbiter  crew  and  Tug  Operations 
Center  will  concur  that  the  Tug  is  ready  for  deployment 

32215  Deploy  Tug 

V 

The  scheduled  time  allowed  for  the  deployment  sequence  is  twenty  minutes  This 
time  is  representative  of  current  procedure  and  hardware  requirements  and- can  vary 
with  refinements  and  changes 

The  deployment  sequence  is  initiated  with  the  Tug  vehicle  on  internal  power  and 
configured  for  deployment  The  Orbiter  crew  begins  the  process  by  disconnecting 
and  retracting  the  fluid  and  payload  umbilicals  and  releasing  the  latches  re- 
taining the  Tug  in 'the  Orbiter  bay  the  next  crew  action  is  the  rotation  of  the 
Tug  by  the  docking  adapter  to  an  angle  where  the  payload  end  -of  the  Tug  is  above 
the  Orbiter  bay  opening  At  this  point  the-c-rew  extends < and 'mates  the  RMS  with 
the  Tug  The  Tug/Orbiter  RF  tel'emetry  and^command  -link  is  then*  establlshedfand 
verified  With  the  verification  of  the  Tug/Orbiter  RF  communications  and 'all 
other  systems  ready  the  Orbiter  Crew  releases  the  Tug  from  the  docking  a'dapter 
and  guides  the  Tug  out  of  the  Orbiter  bay  with  the  RMS  until  the  RMS  is  fully 
extended  With  concurrence  ""from  the  Tug  Operations  Center,  the  Orbiter  will 
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release  the  Tug  from  the  RMS  and  initiate  the  Orbiter  evasive  maneuver  At 
separation  from  the  RMS,  the  Tug  software  will  initiate  active  APS  to  maintain 
attitude  hold  while  the  Orbiter  maneuvers  to  a safe  distance  The  steerable 
antenna  will  search  and  detect  the  TORS  and  establish  downlink  telemetry.  When 
the  Orbiter  has  maneuvered  to  a safe  distance  Tug  control  will  be  relinquished 
to  the  ground 

3.2  2 1 6 Enable  Tug  Systems 

The  command  to  enable  the  remaining  Tug  systems  will  be  issued  by  the  Tug 
Operation  Center  (TOC)  with  the  Orbiter  crew  providing  backup  capability  The 
enable  command  will  be  issued  after  the  Orbiter  crew  has  relinquished  control 
of  the  Tug_  to  the  TOC.  The  acceptance  of  the  Command  by  the  Tug  will  initiate 
the  preprogrammed  attitude  maneuver  for  this  time  period  and  will  institute  the 
activation  of  the  mam  propulsion  system 

32217  Check  and  Verify  Tug  Systems 

The  Tug  systems  checks  will  nominally  be  conducted  by  automatic  sequence 
controlled  by  the  Tug  DMS  The  test  sequence  data  will  be  telemetered  and 
monitored  by  TOC  personnel  who  will  have  command  options  at  their  disposal  for 
unexpected  or  suspect  condition  investigation  Alternate  plans  may  be  imple- 
mented if  malfunctions  are  detected 

3 2.2  1 8 Mission  Enable 

If  no  perturbations  occur  during  the  on  orbit  initialization  and  checkout  of 
the  Tug,  then  the  Tug  mission  sequence  will  be  enabled  by  either  the  DMS  or  by 
TOC  command  At  this  time  the  DMS  will  enter  the  on  orbit  coast  mode  in 
preparation  for  the  first  main  engine  burn 

3222  On-Orbit  Coast  Module 

The  On-Orbit  Coast  Module  provides  the  interim  on  orbit  navigation  guidance  and 
control  state  between  active  mission  modules.  During  these  waiting  periods  the 
overall  mission  plan  can  be  reviewed  and  modified  to  accommodate  real  time 
mission  variations  The  duration  of  time  spent  in  this  module  will  be  a function 
of  the  sequenced  mission  schedule  maintained  by  the  DMS  in  the  Tug  flight 
program.  During  this  mode  the  navigation  update  sequence  and  on-orbit  mission 
planning  sequence  may  be  entered  by  ground  command  or  as  a result  of  special 
conditions  for  handling  unscheduled  but  necessary  mission  changes.  Figure 
3 2 2-2  is  a flow  diagram  showing  the  module  functional  capability  and  the 
potential  interface  with  other  modules  Table  3 2.2-2  is  a listing  of  the  major 
Tug  and  TOC  events  contained  in  this  module. 

32221  On-Orbit  Guidance  Navigation  and  Control 

The  On-Orbit  GN&C  Module  provides  for  the  maintenance  of  the  Tug  attitude  and 
trajectory  during  the  periods  between  mainstage,  trimburns,  target  rendezvous 
and  docking,  payload  placement,  service,  retrieval  and  Orbiter  retrieval.  If 
a navigation  update  is  required  the  sequence  can  be  commanded  and  accomplished 
during  this  time 
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Figure  3 2 2-2  Standard  On-Orbit  Coast  Module 
32222  On-Orbit  Mission  Planning 

The  nominal  mission  will  not  require  any  adjustment  in  the  preplanning  sequence 
of  events  However,  should  major  perturbations  occur,  such  as  missed  first 
mamstage  opportunity,  e,arly  engine  cutoff  or  anything  negating  the  nominal 
sequence,  then  the  capability  exists  through  this  function  to  change,  by  reloading 
the  DMS,  the  mission  sequence  in  a manner  best  suited  to  the  current  realtime 
conditions 

3 2 2 3 Mamstage  Module 

The  Mamstage  Module  is  utilized  each  time  the  Tug  must  make  a major  maneuver 
such  as  a phasing  burn,  transfer  orbit  burn,  large  midcourse  correction,  and/or 
circularization  This  module  is  entered  with  the  Tug  in  the  on  orbit  coast  mode 
and  exits  to  the  on  orbit  coast  mode  after  accomplishing  the  desired  major 
thrusting  maneuver  Nominal  time  in  the  module'  as  currently  defined  is  composed 
of  approximately  fifteen  minutes  preburn  preparations,  the  burn  maneuver,  and 
three  minutes  post  burn  operations-  Figure  3 2 2-3  depicts  by  flow  chart  the 
major  function  sequence  within  the  module  Table  3 2 2-3  lists  the  major  Tug 
and  TOC  events  and  their  respective  times 
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STANDARD  ON  ORBIT  COAST  MODULE  (05) 

ENTRY 

Orbitcr  Launch  Operation,  Mainstage,  Trlmburn,  Paj load 

The  on  orbit  coast  module  provides  the  interim  on  orbit  navigation  guidance  and  con- 

Placement , Payload  Service,  and  Payload  Retrieval 

trol  state  between  active  mission  modules 
mission  plan  can  be  reviewed  and  modified 

During  these  waiting  periods  the  overall 
to  accomodate  realtime  mission  -variations 

EXIT 

Mainstage,  Trimburn,  Payload  Placement,  Rendezvous,  j 

Payload  Service,  Payload  Retrieval,  and 

Orbiter  Retrieval 

EVENT  DESCRIPTION 


EVENT  NUMBER 


TIME  IN 
MISSION 
(HOURS) 


Event  time  in  minutes 
Reference  Time 


ON  ORBIT  GN&C 


ON  ORBIT  NAVIGATION 
ON  ORBIT  ATTITUDE  CONTROL 
MONITOR  TUG  SYSTEMS 
TRACK  SPACE  TUG 
MAINTAIN  TUG  EPHEMERIS 
MAINTAIN  TARGET  EPHEMERIS 
MONITOR  CONSUMABLES  USAGE 
NAVIGATION  UPDATE  AS  REQUIRED 
TARGET  UPDATE  AS  REQUIRED 
ATTITUDE  UPDATE  AS  REQUIRED 

ON  ORBIT  MISSION  PLANNING 


COMPUTE  1ST  AND  2ND  OPPORTUNITY 
TARGET  PARAMETERS 
COMPUTE  1ST  AND  2ND  OPPORTUNITY 
BURN  PARAMETERS 
PLAN  OPTIMUM  MISSION  EVENT 
SEQUENCE  FOR  1ST  AND  2ND  OPPOR- 
TUNITY 

VERIFY  1ST  AND  2ND  OPPORTUNITY 
PARAMETERS  AND  EVENT  SEQUENCE 
MEMORY  LOAD 


01  07 

01  08  00  017 

01  09  00  017 

01  10  00  017 

02  00  00  083 

02  01  00  017 

02  02  00  017 

02  03  00  017 


02  04  I 00  033 


i — s — j — i — i — j — ) — i — f- 
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Figure  3 2 2-3  Standard  Ma instage  Module 


Table  3 22-3  Standard  Matnstage  Module 


STANDARD  MAINSTAGE  MODULE  (02) 

The  mains tage  module  Is  utilized  each  time  the  Space  Tug  must  make  a major  maneuver 
such  as  a phasing  burn,  transfer  orbit  burn,  large  mid-course  correction,  circular- 
ization, etc  This  module  is  entered  with  the  Space  Tug  in  the  on-orbit  coast  mode 
and  exits  in  the  on-orbit  coast  mode  after  the  accomplishment  of  the  desired  major 


EVENT  DESCRIPTION 

EVENT  NUMBER 

UPDATE  TARGETING  PARAMETERS 

oi  oo ; 

EVALUATE  ORBIT  AND  TRAJECTORY 

EVALUATE  GN&C  SYSTEM 

JAVIGATION  UPDATE 

ATTITUDE  UPDATE 

01  06 

TARGET  UPDATE 

01  05 

EVALUATE  PROPULSION  & MASS  STATUS 

01  06 

CALCULATE  ORBIT  CHANGE  MANEUVER 

01  07 

AND  UPLINK  CHANGES  TO  TUG 

MISSION  PLAN 

PREPARE  SYSTEM  FOR  MANEUVER 

02  00 

MANEUVER  TO  BURN  ATTITUDE 

02  01 

ALL  SYSTOtS  TO  BURN  CONFIGURATION 

02  02 

START  BURN  LOGIC  SEQUENCE 

02  03 

MONITOR  AND  COMMAND  STANDBY 

02  04 

PERFORM  ENGINE  BURN 

03  00 

INITIATE  BURN  SEQUENCE 

03  01 

INITIATE  MAINSTAGE  CN&C 

03  02 

START  ENGINE 

03  03 

NO  IGNITION  (REVERT  TO  ON  ORBIT 

03  04 

NAVIGATION  AND  SELECT  2ND  OPPORTUN- 

ITY MISSION  PLAN) 

MONITOR  EVENT  SEQUENCE 

03  05 

GROUND  BACKUP  ENGINE  CUTOFF  COMMAND 

03  06 

INITIATE  AND  PERFORM  BURN  TRACKING 

03  07 

TERMINATE  BURN 

04  00 

CALCULATE  AND  ISSUE  ENGINE 

04  01 

CUTOFF  (TUG  SOFTWARE) 

TELEMETER  BURN  DATA 

04  02 

EXIT  SEQUENCE  TO  ON  ORBIT  NAVIGATION 

* 04  03 

MONITOR  CUTOFF  AND  PROVIDE  GROUND 

04  04 

BACKUP  ENGINE  CUTOFF  COMMAND 

COMPARE  CALCULATED  AND  ACTUAL  BURN 

04  05 

DATA 

INITIATE  COAST  TRACKING 

04  06 

DURATION 


TIME  IN 
MODULE 


(HOURS)  (HOURS) 


TIME  IN 
MISSION 
(HOURS) 


00 

083 

00 

033 

00 

033 

00 

017 

00 

017 

00 

017 

00 

033 

OO 

050 

00 

150 

00 

050 

00 

083 

00 

017 

00 

150 

00 

133 

00 

017 

00 

017 

00 

017 

00 

017 

00 

116 

00 

116 

00 

116 

00 

050 

00 

017 

00 

017 

00 

017 

00 

017 

00 

050 

00 

017 

- 0 250 

- 0 250 

- 0 250 

- 0 217 

- 0 200 

- 0 183 

- 0 250 

- 0 217 


- 0 167 

- 0 167 

- 0 117 

- 0 033 

- 0 167 

- 0 017 

- 0 017 

- 0 017 
REF 

0 017 


O 133 
0 133 
0 133 

0 000 


REF 

0 000 
0 000 
0 000 

O 001 

0 000 


32231  Update  Targeting  Parameters 

This  five  minute  portion  of  the  module  permits  the  evaluation  of  the  trajectory 
and  a navigation  and  target  update  if  required  The  calculations  for  the  burn 
attitude  and  start  and  stop  times  are  accomplished  by  the  Tug  flight  program 

32232  Prepare  Systems  for  Maneuver 

This  sequence  occurs  immediately  prior  to  the  main  engine  burn  The  Tug  is 
oriented  by  the  APS  to  the  proper  attitude  for  burn  initialization  The  mam 
propulsive  system  is  configured  for  engine  ignition 

32233  Perform  Engine  Burn 

At  approximately  one  minute  prior  to  engine  ignition  the  burn  sequence  is 
entered  and  the  mainstage  GN&C  is  initiated  If  the  scheduled  mainstage 
ignition  should  fail  to  occur,  the  flight  program  will  terminate  the  burn 
sequence  and  revert  to  the  on  orbit  coast  mode  For  the  first  mainstage  burn, 
a second  opportunity  sequence  will  be  resident  in  the  flight  program  and  will 
be  automatically  implemented  if  required 

Prior  to  mainstage  ignition,  the  TOC  will  imtate  burn  tracking  if  tracking  is 
part  of  the  operations  system  and  will  also  monitor  and  verify  the  on  board 
events  as  they  occur  During  the  active  mainstage  burn,  the  TOC  will  monitor 
the  vehicle  events,  and  trajectory  and  provide  backup  engine  cutoff  through 
the  command  system 

32234  Terminate  Burn 

The  terminating  sequence  for  engine  burn  has  been  allowed  three  minutes  in  the 
timeline  but  should  occur  at  a more  rapid  pace  The  mam  engine  cutoff  will  be 
calculated  and  issued  by  the  flight  program  and  the  terminal  burn  parameters 
telemetered  The  TOC  will  provide  backup  engine  cutoff  capability  The  TOC 
will  terminate  burn  tracking  and  evaluate  the  burn  end  conditions  to  determine 
if  burn  objectives  have  been  met  The  flight  program  will  automatically  exit 
to  the  on  orbit  coast  mode  where  mission  plans  can  be  modified  and  a trim  burn 
scheduled  if  required 

3224  Trimburn  Module 

The  Trimburn  Module  is  utilized  whenever  the  mam  engine  is  operated  in  the 
tankhead  idle  or  in  the  pump  mode  or  when  the  APS  is  utilized  for  minor  orbit 
corrections  As  with  the  Mainstage  Module,  the  Trimburn  Module  is  entered  from 
the  on  orbit  coast  mode  and  exists  to  the  on  orbit  coast  mode  after  completion  of 
the  desired  thrusting  Nominal  time  allowed  m the  timeline  for  initiating  a trim- 
burn  maneuver  is  approximately  ten  minutes  plus  the  duration  of  the  burn  and  three 
minutes  for  burn  termination  Figure  3 2 2-4  illustrates  the  flow  of  the  major 
functions  within  the  module  Table  3 2 2-4  lists  the  major  Tug,  TOC  events  and 
their  respective  times 
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Figure  322-4  Standard  Tnmburn  Module 
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Table  3.22-4  Standard  Trimburn  fylodule 


STANDARD  TRIMBURN  MODULE  (03) 

The  trim  bum  module  is  utilized  whenever  the  ma,in  engine  is  aperated  in  the  tank- 
head  idle  or  in  the  pump  mode  or  when  the  APS  system  is  utilized  for  minor  orbit 
corrections  As  with  the  main  stage  module,  the  trim  bum  module  is  entered  from  the 
on-orbit  coast  mode  and  exits  to  the  on-orbit  coast  mode  after  completion  of  the 


ENTRY 

EXIT 


On  Orbit  Coast 
On  Orbit  Coast 


EVENT  DESCRIPTION 

EVENT  NUMBER 

EVENT 
DU RATI 
(HOURS 

LOAD  BURN  PARAMETERS 

01  00 

00  050 

EVALUATE  ORBIT  AND  TRAJECTORY 

01  01 

00  033 

EVALUATE  GNSC  SYSTEM 

01  02 

00  033 

NAVIGATION  UPDATE 

01  03 

00  017 

ATTITUDE  UPDATE 

01  04 

00  017 

TARGET  UPDATE 

01  05 

00  017 

CALCULATE  TRIMBURN  MANEUVER 

01  06 

00  033 

PARAMETERS 

SELECT  TRIM  BURN  MODE  ! 

01  07 

00  017 

(PUMP,  THI,  or  APS) 

SELECT  EVENT  SEQUENCE 

01  08 

00  017 

PREPARE  SYSTEM  FOR  MANEUVER 

02  00 

00  050 

MANEUVER  TO  BURN  ATTITUDE 

02  01 

00  050 

ALL  SYSTEMS  TO  TRIM  BURN  CONFIGU- 

02  02 

00  017 

RATION 

START  TRIMBURN  LOGIC  SEQUENCE 

02  03 

00  017 

MONITOR  AND  COMMAND  STANDBY 

02  04 

00  050 

PERFORM  ENGINE  BURN 

03  00 

00  067 

INITIATE  BURN  SEQUENCE 

03  01 

00  017 

INITIATE  TRIM  BURN  GN&C 

03  02 

00  017 

START  TRIM  BURN  THRUST 

03  03 

00  017 

MONITOR  EVENT  SEQUENCE  AND  COMMAND 

03  04 

00  067 

STANDBY 

INITIATE  AND  PERFORM  TRIMBURN 

03  05 

00  067 

TRACKING 

TERMINATE  BURN 

04  00 

OO  050 

CALCULATE  AND  ISSUE  ENGINE 

04  01 

00  017 

CUTOFF  (TUG  SOFTWARE) 

TELEMETER  BURN  DATA 

04  02 

00  017 

EXIT  SEQUENCE  TO  ON  ORBIT  COAST 

04  03 

00  017 

MONITOR  CUTOFF  AND  PROVIDE  GROUND 

04  04 

00  017 

BACKUP  ENGINE  CUTOFF  COMMAND 

COMPARE  CALCULATED  AND  ACTUAL  BURN 

04  05 

00  050 

DATA 

INITIATE  COAST  TRACKING 

i 

04  06 

00  017 

EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 

0 167 

0 167 
0 167 
0 167 
0 150 
0 133 
0 167 

0 133 

0 133 

0 117 

0 117 
0 100 

0 083 
0 117 

- 0 067 

- 0 067 

- 0 050 

- 0 033 

- 0 067 

- 0 067 


I REF 

0 000 

0 000 
0 000 
0 000 

0 000 

0 000 


EVENT 
START 
TIME  IN 
MISSION 
(HOURS) 


32241  Load  Burn  Parameters 

This  sequence  of  events  permits  the  incorporation  of  a preburn  navigation  target 
and  attitude  update  if  desired  The  calculation  of  burn  attitude,  burn  start 
and  stop  time,  and  burn  select  (Pump,  Tank  Head  Idle  (THI)  or  APS)  is  also 
accomplished  in  the  on  orbit  coast  mode  and  will  be  deleted  from  this  time 
frame  if  not  required 

3 2 2 4 2 Prepare  Systems  for  Maneuver 

This  sequence  immediately  precedes  the  trimburn  thrust  maneuver.  The  Tug  is 
oriented  by  the  APS  to  the  trimburn  attitude  If  the  mam  propulsion  system 
is  to  be  utilized,  it  is  readied  for  the  selected  burn  mode.  (Pump  or  THI) 

32243  Perform  Engine  Burn 

Just  prior  to  the  initiation  of  trimburn  thrust  the  Tug  flight  program  initiates 
Trimburn  GN&C  The  GN&C  used  during  this  state  will  vary  depending  on  the 
thrust  mode  employed  If  the  use  of  tracking  is  planned  the  TOC  will  start 
burn  tracking  and  monitor  burn  performance 

32244  Terminate  Burn 

The  terminate  sequence  for  the  trimburn  maneuver  will  be  similar  to  that  employed 
by  the  Mainstage  Module.  The  burn  cutoff  will  be  calculated  and  issued  by  the 
the  flight  program-  and  the  TOC  will  provide  backup  command  cutoff  capability. 

Burn  end  condition  data  will  be  telemetered  to  the  TOC  for  evaluation  and  the 
sequence  will  exit  to  the  on  orbit  coast  mode 

3225  Payload  Placement  Module 

The  Payload  Placement  Module  incorporates  the  activities  required  to  check  out 
and  deploy  a Spacecraft  After  phasing  away  from  the  deployed  Spacecraft  the 
Tug  enters  the  on  orbit  coast  or  Docking  Module  depending  on  the  mission.  In 
the  case  where  the  mission  requirement  is  to  rendezvous  with  an  existing  on  orbit 
Spacecraft  before  deployment  of  the  Tug  payload,  the  rendezvous  can  be  accom- 
plished, the  on  board  payload  deployed,  and  the  Docking  Module  entered  before 
the  on  orbit  Spacecraft  is  retrieved  Figure  3 2.2-5  is  a flow  diagram  showing 
the  module  functional  capabilities  and  interfaces  with  other  modules  Table 
3 2 2-5  is  a listing  of  payload  placements  events  and  their  respective  duration 
times 

32251  Payload  Command  and  Control 

During  this  sequence  of  events  the  Spacecraft  to  be  deployed  is  initialized 
and  enabled  to  accept  commands  Critical  parameters  are  available  through  Tug 
telemetry  for  ground  control  observation 

32252  Prepare  Tug  Systems  For  Deployment  And  Checkout  Of  Payload 

The  Tug  will  maneuver  to  the  appropriate  attitude  for  checkout  of  the  Space- 
craft Checkout  of  the  Spacecraft  will  be  initiated  by  the  DMS  and  conducted 
by  automatic  sequence  Should  a malfunction  occur  it  will  be  possible  to  safe 
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Table  322-5  Standard  Payload  Placement  Module 


STANDARD  PAYLOAD  PLACEMENT  MODULE  (07) 

The  payload  placement  module  defines  the  activities  required  to  checkout  and  deploy 
a satellite,  leaving  Che  Space  Tug  in  the  on-orbit  coast  mode  phasing  away  from 
the  deployed  satellite 


ENTRY  On  Orbit  Coast,  Rendezvous 

EXIT  On  Orbit  Coast,  Docking 


EVENT  DESCRIPTION 


EVENT  NUMBER 


EVENT 

DURATION 

(HOURS) 


EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 


EVENT 
START 
TIME  IN 
MISSION 
(HOURS) 


Event  time  in  minutes 


Reference  Time 
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PAYLOAD  COMMAND  AND  CONTROL 

INITIALIZE  PAYLOAD  SYSTEMS 
ENABLE  COMMAND  ACCEPT 
SEQUENCE  PAYLOAD  CHECKOUT 
MONITOR  MISSION  CRITICAL  PARAMETERS 
DEPLOYMENT  ABORT  LOGIC 


01  00 

01  01 
01  02 
01  03 
01  04 
01  05 


00  133 

00  050 
00  017 
00  100 
00  117 
00  117 


0 433 
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417 

417 
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PREPARE  TUG  SYSTEMS  FOR  DEPLOYMENT 


ACTIVATE  DOCKING  SYSTEM 
MANEUVER  TO  CHECKOUT  ATTITUDE 
CALL  CHECKOUT  SOFTWARE 
PREPARE  MECHANICAL  LATCH  UNLOCK 
CALL  STANDBY  DYNAMICS  SOFTWARE 

CHECKOUT  PAYLOAD  (INITIAL) 

INITIATE  CHECKOUT  ROUTINE 
MONITOR  STATUS 
COMMUNICATE  STATUS 

POSITION  PAYLOAD  FOR  RELEASE 

MANEUVER  TO  DEPLOYMENT  ATTITUDE 
MOVE  MECHANISM  TO  READY 

ACTIVATE  PAYLOAD  SYSTEMS 

DEPLOY  SOLAR  PANELS  (AS  REQ’D) 
DEPLOY  P/L  ANTENNAE  (AS  REQ'D) 
PAYLOAD  ON  INTERNAL  POWER 
PAYLOAD  ATTITUDE  CONTROL  STANDBY 
PAYLOAD  NAVIGATION  SYSTEM  GO 
LOAD  NAVIGATION  DATA 
PAYLOAD  SELF-SUFFICIENT 

CHECKOUT  PAYLOAD  (FINAL) 

CALL  FINAL  CHECKOUT  SOFTWARE 
MONITOR  STATUS 
INIT1ATF  CHECKOUT  ROUTINE 
COMMUNICATE  STATUS 


02  00 


02  01 
02  02 
02  03 
02  04 
02  05 


03  00 


00  083 

00  017 
00  067 
00  033 
00  033 
00  067 

00  050 


- 0 417 

- 0 417 

- 0 417 

- 0 417 

- 0 417 

- 0 417 

- 0 400 


03  01 
03  02 

03  03 

04  00 

04  01 

04  02 

05  00 


00  017 
00  050 
00  033 

00  067 

00  050 
00  033 

00  083 


- 0 400 

- 0 400 

- 0 383 

- 0 383 

- 0 383 

- 0 367 

- 0 367 


05  01 
05  02 
05  03 
05  04 
05  05 
05  06 

05  07 

06  00 

06  01 
06  02 
06  03 
06  04 


00  067 
00  067 
00  017 
00  017 
00  017 
00  050 
00  017 

00  083 

00  033 
00  083 
00  083 
00  067 


- 0 367 

- 0 367 

- 0 367 

- 0 367 

- 0 350 

- 0 333 

- 0 317 

- 0 250 

- 0 250 

- 0 250 

- 0 250 

- 0 233 
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Table  3 2 2-5  Standard  Payload  Placement  I lodute  ( Continued) 
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STANDARD  PAYLOAD  PLACEMENT  MODULE  (07)  (CONTINUED) 


EVENT  DESCRIPTION 


EVENT  NUMBER 


EVENT 

DURATION 

(HOURS) 


EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 


EVENT 
START 
TIKE  IN 
MISSION 
(HOURS) 


ABORT  PAYLOAD  DEPLOYMENT 

RECEIVt  NO-GO  FROM  FINAL  CHECKOUT 
CALL  DE-ACTIVATION  SOFTWARE 
SEQUENCE  DOWN  PAYLOAD  SYSTEMS 
INITIATE  ALTERNATE  MISS-  SEQUENCE 
RETRACT  LATCHES  TO  ’HARD  DOCK 
COMMUNICATE  STATUS 

TERMINATE  PLACEMENT 

SECURE  ALL  PAYLOAD  SYSTEMS 
JETTISON  ALL  PPOTURBANCES 
CONFIGURE  TO  CO  1ST  MODE 

COUNTDOWN  (■  RELEASE  PAY  LOAD 

INITIATE  COUNTDOWN  srQUENCr 
ACHIEVE  DESlRED  Rrl  EASL  POINT 
EN \B!  E PAYLOAD  ATTITUDE  C0NTR01 
DETACH  MECH  4 LLEC  UMBILICALS 
SI  IN-liP  P iT  LOAD  (IF  REQUIRED) 
RFLFASE  CAPTURE  LATCHES 
ACTIVArE  TV  MONITOR 
RFLEASt  FINAL  LATCHES 
llACt  OUT  AND  STATION  kf- bP 

COMMAND  AND  CONTROL  PAYLOAD 


ES1\BLrSK  TWO-WAY  KF  COMMUNICATION 
FLY  AROUND  PAYLOAD 
PERFORM  VI SUL A INSPECTION 
MONITOR  PAYLOAD  PARAMETERS 
COMMAND  VERNIER  -1ANEUVLRS 

PERFORM  JOINT  PAYLOAD  OPERATIONS 


COMMAND  PAY  LOAD  SEQUENCES 

CONDUCT  JOINT  TUG /PAYLOAD  OPERATIONS 

TURN  OVER  CONTROL  TO  POC 


07 

00 

00 

117 

m 

00 

017 

E§ 

00 

033 

BEX 

00 

050 

07 

04 

00 

100 

07 

05 

00 

017 

07 

06 

00 

083 

08 

00 

00 

067 

08 

01 

00 

050 

08 

02 

00 

050 

08 

03 

00 

050 

09 

00 

00 

200 

09 

01 

00 

150 

0° 

02 

00 

067 

09 

03 

00 

167 

09 

04 

00 

033 

09 

05 

00 

050 

09 

06 

00 

033 

09 

07 

00 

083 

09 

08 

00 

017 

09 

09 

00 

05 0 

10 

00 

00 

117 

10 

01 

00 

050 

10 

02 

00 

117 

10 

03 

00 

117 

10 

04 

00 

067 

10 

05 

00 

067 

11 

00 

00 

117 

II 

01 

00 

100 

11 

02 

00 

083 

11 

03 

O0 

017 

- 0 

233 

- 0 

233 

- 0 

233 

- 0 

237 

- 0 

217 

- 0 

200 

- 0 

200 

- 0 

183 

- 0 

183 

- 0 

163 

- 0 

167 

- 0 

150 

- 0 

150 

- 0 

133 

- 0 

117 

- 0 

100 

- 0 

083 

- 0 

053 

- 0 

033 

RH- 

0 

000 

0 

017 

0 

017 

0 

017 

0 

017 

0 

067 

0 

06, 

0 

083 

0 

083 

0 

100 

0 

183 

Reference  Time 


Event  cine  In  minutes 


3-30 


Table  3 2 2-5  Standard  Pa yload  Placement  I lodule  (Continued) 


Reference  T«me 


Event  time  in  minutes 


the  Spacecraft  and  return  with  the  Tug  to  the  Orbiter  if  mission  plans  and 
propellant  supplies  allow  With  checkout  complete  the  Tug  will  then  maneuver 
«,o  the  proper  attitude  for  deployment  and  the  final  activation  of  Spacecraft 
checks  may  be  conducted  at  this  time  Again  the  placement  of  the  Spacecraft 
may  be  aborted  at  this  time  if  a malfunction  is  detected 

32253  Countdown  And  Release  Of  Payload 

The  final  sequence  for  release  will  depend  on  the  type  of  Spacecraft  but  will 
generally  be  accomplished  by  releasing  the  holding  latches  and  a slow  withdrawal 
maneuver  executed  by  the  Tug  Prior  to  release  all  electrical  and  other  connec- 
tions will  be  severed  and  for  some.  Spacecraft  spin  up  will  be  required  After 
withdrawal  to  a safe  distance  and  with  a constant  separation  rate  m progress, 
the  Tug  will  enter  the  on-orbit  coast  mode 

3226  Rendezvous  Module 

The  Rendezvous  Module  defines  the  operations  required  for  the  Tug  to  move 
from  a coplanar  phasing  orbit  to  a point  sufficiently  near  a target  Spacecraft 
for  docking  to  be  initiated  The  component  submodules  are  Rendezvous  Acquisi- 
tion, Terminal  Phase  Initiating  (TPI),  and  Terminal  Phase  Transfer  (TPT) 

Figure  3 2 2-6  is  a flow  diagram  showing  the  module  functional  capability  and 
interfaces  Table  3 2 2-6  is  a listing  of  Tug,  Spacecraft,  and  TOC  events 
comprised  in  this  module 

32261  Rendezvous  Acquisition 

During  this  submodular  operation,  the  rendezvous  tracker  search  is  implemented, 
the  Spacecraft  is  acquired  and  tracked  and  the  Tug  stage  vector  is  updated  to 
be  consistent  with  the  tracking  information  from  the  previously  uplinked  Space- 
craft vector 

32262  Terminal  Phase  Initiation 

This  submodule  is  defined  separately  from  Terminal  Phase  Transfer  because  the 
main  engine  will  be  employed  m TPI  All  targetting  calculations  for  selecting 
the  transfer-arc  geometry  as  well  as  the  burn  parameters  for  producing  that  trans- 
fer arc  are  calculated  m TPI  Following  this  a standard  Trimburn  Module,  de- 
scribed in  Section  3 2 2 4 is  implemented 


ENTRY  EX|T 


Figure  3 2 2-6  Standard  Rendezvous  Module 
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Table  3 22-6  Standard  Rendezvous  Module 


STANDARD  RENDEZVOUS  MODULE  (04) 

The  Rendezvous  Module  contains  the  events  associated  with  the  initial  contact 
and  closing  maneuvers  between  the  Tug  and  spacecraft  with  which  the  Tug  is  to 
dock  Included  is  acquisition,  terminal  phase  initiation  and  the  orbital  transfer 
to  a range  sufficiently  small  for  docking  to  commence 


ENTRY  On  Orbit  Coast 

EXIT  Docking,  Payload  Placement 


EVENT  DESCRIPTION 

EVENT  NUMBER 

EVENT 

DURATION 

(HOURS) 

EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 

RENDEZVOUS  ACQUISITION 

01  00 

0 183 

- 0 183 

TARGET  EPHEMERTS  UPDATE 
(VIA  UPLINK) , DETERMINATION 
OF  INITIAL  VECTOR  TO  TARGET 
AND  ACTIVATE  RENDEZVOUS 
SENSOR 

01  01 

0 017 

- 0 183 

VALIDATE  SENSOR,  SEARCH 
FOR  TARGET 

01  02 

0 167 

- 0 167 

ACQUIRE  TARGET,  VALIDATE 
DIFFERENCE  OF  VECTOR  FROM 
PREDICTION 

01  03 

0 017 

REF 

UPDATE  TARGET  EPHEMERIS 

01  04 

0 017 

0 017 

TERMINAL  PHASE  INITIATION 

02  00 

0 167 

0 033 

CALCULATE  RENDEZVOUS  PARAMETERS 

02  01 

0 017 

0 033 

PERFORM  TRIM  BURN 

02  02 

0 150 

0 050 

TERMINAL  PHASE  TRANSFER 

03  00 

1 167 

0 217 

MANEUVER  TO  PARALLEL 
LONGITUDINAL  AXIS  TO  LINE  OF  SIGHT 

03  01 

0 033 

0 217 

REACQUIRE  SPACECRAFT 

03  02 

0 050 

0 250 

VALIDATE  TRANSFER  TRAJECTORY 

03  03 

0 083 

0 300 

TRANSFER  ORBIT  COAST  TRIM  BURN 
IF  REQUIRED  (TANK  HEAD  IDLE) 

03  04 

0 050 

0 383 

TRANSFER  ORBIT  COAST,  INITIAL 
SEARCH  WITH  DOCKING  SENSORS 

03  05 

0 933 

0 433 

ACTIVATE  ACS  TRANSLATIONAL  CONTROL 
SYSTEM  AT  THE  TRANSITION  GATE 

03  06 

0 017 

1 366 

EVENT 
START 
TIME  IN 
MISSION 
(HOURS) 


Event  time  in  minutes 
Reference 
Time 
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32263  Terminal  Phase  Transfer 

This  module  contains  the  balance  of  rendezvous  following  TPI  The  Tug  will  be 
pointed  directly  toward  the  Spacecraft  and  will  track  it  throughout  TPT  unless 
the  attitude  must  be  changed  for  trimming  the  trajectory  or  braking  prior  to 
initiating  docking  procedures  Early  m the  transfer,  if  tracking  defines 
significant  error,  one  or  more  small-impulse  trimburns  will  be  implemented  The 
range  and  required  impulse  for  at  least  two  braking  gates  will  be  calculated 
following  each  trim-burn  and  will  be  periodically  updated  as  transfer-arc 
dispersions  are  identified  by  rendezvous  tracking 

3227  Docking  Module 

The  Docking  Module  defines  the  operations  executed  by  the  Tug  from  the  last 
braking  gate  until  latching  with  the  target  Spacecraft  has  occurred  The 
submodules  include  inspection  and  alignment,  closure,  and  terminal  docking  Two 
significant  differences  from  rendezvous  are  the  requirements  that  the  Tug 
maneuvers  relative  to  the  Spacecraft  attitude  and  Tug  maneuvering  is  not  con- 
strained by  orbital  mechanics  Figure  3 2 2-7  illustrates  the  module  flow 
diagram  and  Table  322-7  is  a list  of  events  comprised  in  the  module 

32271  Inspection  And  Alignment 

Following  the  last  braking  at  the  exit  from  Rendezvous,  the  Tug  will  continue 
closing  with  the  target  Spacecraft  but  now  under  phase-plane  translational 
control  referenced  to  the  target  Upon  reaching  the  preset  minimum  safe  non- 
dockmg  range,  the  locus  of  which  forms  a safety  sphere,  the  Tug  will  circum- 
navigate the  target  Spacecraft  to  support  televised  inspection  by  the  TOC  and 
SCOC  During  this  phase  the  docking  tracker  is  searching  for  the  docking-aid 
reflectors  mounted  on  the  Spacecraft  Circumnavigation  will  comprise  a set  of 
mutually  perpendicular  orbits  followed  by  another  set  until  the  TOC  commands 
the  Tug  to  proceed  with  alignment  and  the  docking  aids  are  acquired  and  being 
tracked 

32272  Closure 

The  closure  submodule  contains  the  lateral  and  closure  translation  required  to 
align  the  Tug  to  the  target  docking  axis  at  the  commit  range,  which  is  the  range 
just  greater  than  that  at  which  the  track  of  the  peripheral  reflectors  is  lost 
preventing  relative  attitude  determination  If  a hold  command  has  not  been 
received  from  the  TOC  and  if  the  lateral  attitude  errors  are  within  docking 
latch  tolerances,  the  Tug  transitions  smoothly  into  the  next  operational  module, 
Terminal  Docking 

32273  Terminal  Docking 

The  fixed-attitude  closure  down  the  docking  axis  at  the  optimum  contact  speed, 
the  initial  and  final  latches  and  the  establishment  of  the  umbilical  interfaces 
are  included  in  Terminal  Docking  Range,  range  rate  and  lateral  displacement 
error  are  determined  from  the  information  derived  from  tracking  the  central 
docking-aid  reflector  A failure  to  execute  initial  latch  at  impact  will  cause 
the  Tug  to  automatically  revert  to  the  Commit  Range  and  await  an  enabling  command 
before  attempting  to  re-dock 
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Table  322-7  Standard  Docking  Module 
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STANDARD  DOCKING  MODULE  (08) 

ENTRY 

Rendezvous,  Payload  Placement 

The  Docking  Module  contains  the  events  for  maneuvering  relative  to  a subject 
spacecraft  and  'docking  with  it 

EXIT 

Payload  Retrieval,  Service 

EVHHT  DESCRIPTION 


DOCKING  PHASE  INITIATION 


CONTINUE  CLOSURE 
CONTINUE  DOCKING  AID  SEARCH 
TERMINATE  AT  TARGETTED 
MINIMUM  SATE  APPROACH  RANGE 

INSPECTION  AND  DOCKING  ALIGNMENT 


CIRCUMNAVIGATE  THE  TARGET 
FOR  INSPECTION  AND  DOCKING 
PORT  LOCATION 


DOCKING  AID  ACQUIRES  DOCKING 
TARGET  (PRE-CONDITION) 

CLOSE  TO  BE  ON  AXIS  AT  THE 
DOCKING  SENSOR  MINIMUM  RANGE 

TERMINAL  DOCKING 


CLOSE  TO  PORT 
LATCH  TO  TARGET,  MATE 
UMBILICAL,  VERIFY  MECHANICAL 
AND  ELECTRICAL  INTEGRITY 


EVENT  NUMBER 


EVENT  EVENT 

START  START 

TIME  IN  TIME  IN 

MODULE  MISSION 

(HOURS)  (HOURS) 


0 183  1-0  183 


2 000  O 000 

2 000  REF 


0 067  ‘1 


Event  time  in  minutes 
Ref 

Time  _ . 


0<0  — 


2 Hours 

f - 
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3.2  2 8 Payload  Retrieval  Module 


The  Payload  Retrieval  Module  is  initiated  after  payload  docking  and  passivation 
has  been  accomplished.  The  function  of  the  module  is  to  secure  the  retrieved 
payload  for  return  to  the  Orbiter  by  the  Tug  Figure  3 2 2-8  illustrates  that 
the  module  is  entered  from  the  Docking  Module  and  exits  to  On-Orbit  Coast  Module 
Table  3.2  2-8  lists  the  sequence  of  events  which  prepare  the  payload  for  the 
return  to  the  Orbiter 

32281  Inert  Payload 

After  docking,  the  retrieved  payload  transmitters  are  deactivated  and  any 
pressurants,  propellants,  or  other  active  agents  safed  Safing  could  involve 
a dumping  operation  If  continuous  power  is  necessary  for  payload  maintenance, 
power  transfer  to  the  Tug  will  be  performed.  Appendages  will  be  retracted  and 
stored  and  the  payload  will  be  secured  for  return  to  the  Orbiter 

3229  Standard  Service  Module 

Baseline  Tug  System  Requirements  and  Guidelines  specify  requirements  for  Tug 
capability  to  service  Spacecraft  including  those  which  are  spin-stabilized  and 
those  launched  as  multiple  payloads  Service  concept  capabilities  selected 
as  a basis  for  generation  of  the  Standard  Service  Module  include 

• television,  (two  dimensions  only) 

• modular  Spacecraft  with  modules  designed  for  on-orbit  substitution 

• replacement  of  modules  by  manipulator  or  indexing  mechanism 

• manipulator  capable  of  providing  mechanical  "assists"  to  Spacecraft 

• servicer  docking  interface  to  Spacecraft  capable  of  spin/despin 

• servicer/Tug  capability  of  providing  thermal  support  to  Spacecraft 

• servicer/Tug  capability  of  providing  power,  data  systems  and 
communication  system  support  to  Spacecraft 

Figure  3 2 2-9  illustrates,  m the  central  portion  of  the  figure,  the  functional 
flow  of  Tug  servicing  of  Spacecraft  The  major  events  are  designated  SSM 
(Standard  Service  Module)  one  through  six  The  upper  portion  of  this  figure 
shows  how  the  Standard  Service  Module  fits  within  the  Standard  Docking  Module 
to  implement  docking  with,  and  repair  of,  the  malfunctioning  Spacecraft.  The 
lower  portion  of  the  Figure  shows  how  the  servicing  function  fits  within  the 
Standard  Payload  (Spacecraft)  Placement  Module  to  define  the  re-deployment  of 
Spacecraft  after  servicing  Notice  that  the  Standard  Docking  Module  as 
a whole  fits  within  the  Standard  Payload  Placement  sequence  between 
Events  SPPM  10  and  SPPM  11  This  provides  for  the  recovery  and  service  or 
re-service  of  a Spacecraft  which  fails  its  post  deployment  checkout,  Event 
SPPM  10  Table  3 2 2-9  defines  each  of  the  six  major  events  in  the  Standard 
Service  Module  by  naming  the  sub-events,  their  durations,  their  start  times 
referenced  to  Event  1 0,  and  the  graphical  representation  of  their  relative 
timing  relationships  The  reference  point  for  calculation  of  times  within  the 
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Figure  322-8.  Standard  Payload  Retrieval  Module 


mission  is  the  moment  when  latch  is  achieved  between  the  Tug  and  the  Spacecraft 
to  be  serviced  when  the  Standard  Service  Module  is  being  entered  from  the 
Standard  Docking  Module  When  entered  from  the  Standard  Payload  Placement 
Module,  the  Standard  Service  Module  beginning  time  (reference  time)  is  the 
termination  of  Standard  Payload  Placement  Module  Event  6,  "Checkout  Payload 
(Spacecraft)"  under  conditions  when  checkout  criteria  were  not  met  and  the 
need  for  servicing  was  identified  Under  these  circumstances,;  the  Orbiter,  Tug, 
and  Paylo'ad  conditions  "in  effect  at  the  time  checkout  was  aborted  and’ servicing 
was  begun  may  obviate  some  or  all  of  the  preparations  for  servicing  operations 
which  are  otherwise  scheduled  in  Events  SSM  1,  SSM  2,  and  SSM  3 In  such 
instances,  the  unnecessary  steps  are  bypassed  and  the  reference  time  for  the 
start  of  the  Standard  Service  Module  is  adjusted  appropriately 

3 2 2 9.1  Prepare  Tug  For  Servicing  Operations 

After  the  Tug  and  Spacecraft  are  docked  and  latched,  reorientation  is  begun 
immediately  if  required  to  satisfy  Spacecraft  requirements  for  such  reasons  as, 
thermal  control,  power  generation,  or  communications  Communications  and 
Telemetry  links  which  are  required  for  servicing  operations  are  established  and 
Tug/SC  umbilicals  are  connected  Critical  performance  parameters  are  checked 
through  the  DMS  for  a coarse  check  on  the  advisability  of  continuing  the  servicing 
operation  If  the  decision  is  made  to  continue,  the  Spacecraft  is  despun  (if 
required) ,, otherwise  other  decisions  are  made  as  to  the  .disposition  of  the 
Spacecraft,  possibly  leading  to  ..its  jettisoning  The  only  Spacecraft  in  the 
present  baseline  which  requires  despin  is  the  Large  Radi  O' Observatory  with  a 
spin  rate  of  1/60  rpm  so  a despin  time  of  10  minutes  has  been  allowed  in  the 
timeline  (The  requirement  for  despin  capability  in  the  servicer  might  possibly 
be  obviated  for  presently  baselined  payloads  by  requiring  the  Large  Rad'io 
Observatory  to  despin  itself  by  such  means  as  RCS  ) For  Spacecraft  which 
require  it,  the  Tug  provides  thermal  conditioning  while  servicing  continues 
A closed  circuit  television  inspection  of  the  Spacecraft  is  performed  leading 
to  a decision  to  abort  servicing  or  to  continue  by  configuring  the  Tug  for 
service  operations  Any  Spacecraft  passivation  required  is  then  completed, 
meanwhile,  subsystem  support  to  the  Spacecraft  is  initiated  and  any  reaction 
wheel  braking  required  is  provided  Two  hours  have  been  allowed  for  active 
braking  of  reaction  wheels  If  braking  is  not  required  by  the  Spacecraft,  the 
time  needed  to  prepare  the  Tug  for  Servicing  can  be  approximately  cut  in  half 
(from  just  over  two  hours)  One  hour  has  been  allowed  for  checkout  of  replace- 
ment modules  before  their  installation  in  the  Spacecraft  so  this  begins  about 
an  hour  into  the  servicing  operation  if  braking  is  required,  otherwise  it 
would  begin  when  Spacecraft  passivation  is  completed  Just  before  servicing 
operations  are  to>  begin,  the  Servicer  and  Manipulator  are  checked  out  At 
this  point  the  Tug  is  verified  as  being  ready  to  begin  scheduled>  service 
operations  and  this  is  reported  to  the  ground 
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Table  322-8  Standard  Payload  Retrieval  Module 
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Figure  3JJ-9  Standard  Service  Module 


Table  322-9  Standard  Service  flodule 


Standard  Service  Module  qo) 


The  Sen  ice  lodule  performs  Che  exchange  of  modules  within  the  spacecraft  and 
the  activation  and  checkout  of  Che  serviced  spacecraft 


ENTRY  Docking 

EXIT  On  Orbit  Coast  Payload  Placement 


EVENT  DESCRIPTION 


PREPARE  TUG  PQR  SERVICING  OPS. 

ORI  ENT  TUC/SC  POR  RS  THERMt  , PWR, 
VERIFY  RELCOM,  R TH  LINKS  TO  END, 
CONNECT  TUG/SC  UMBILICALS 
MONITOR  CRITICAL  PARAMETERS 
DESPIN  SPACECRAPT  Ic  REQUIRED 
PROVIDE  THERMAL  CONDITIONINC  TO  S( 
INSPECT  SPACFCRACT  BY  CCTV 
C0Nc  I CURE  TIJC  POR  SERVICING, VERIP' 
COMPLETE  SC  PASSIVATION  IP  REo'd, 
PROVIDE  SUBSYSTEM  SUPPORT  TO  SC 
BRAKE  SC  REACTION  WHEELS  ]P  REO'o 
CHECK  OUT  SFRVICFR  S MANIPULATOR 
CHECK  OUT  REPLACEMENT  MODULES 
TAKE  ENGINEERING  DATA  ON  TUB  % SC 
VF R I py  THE  READY  FOR  SERVICING 
REPORT  STATUS  TO  CROUND 


EVENT  NUMBER 
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Table  3.2  2-9  Standard  Service  f lodu/e  (Continued) 


£ 


EYENT  DESCRIPTION 


JPQST-gFRVICE  CHECKOUT  QP  SC 
[MONITOR  CRITICAL  PARAMETERS 
POSITION  CCTV  TO  OBSERVE  CHECKOUT 
ICONTINUE  TUG  THERM.  COND,  OP  SC, 
CONTINUE  TUG  SUBSVSTEM  SUPFT.TO  SC] 
ACTIVATE  SC  SUBSYSTEMS  MODULES 
CHECKOUT  SC  SUBSYSTEMS  MODULES 
ACTIVATE  MISSION  EOPT.  MODULFS 
OPEN  SENSOR  CONTAMINATION  COVERS 
CHECKOUT  MISSION  EOPT.  MODULES 
CLOSE  SENSOR  CONTAMINATION  COVERS 
CHECK  DEPLOYABILITY  op  APPENDAGES 
CHECK  Rc  LINKS  TO  GROUND 
TAKE  PRAME  OP  ENGINEERING  DATA 
[REPORT  STATUS  TO  GROUND 
DECISION  TO  RE-SERVICE  OR  DEPLOY 


Standard  Service  Module  (continued) 


PERPQRM  UNSCHEDULED 

MONITOR  CRITICAL  PARAMETERS 
POSITION  CCTV  TO  OBSERVE  SERVICE 
CONTINUE  TUG  THERM,  COND,  OP  SC, 
CONPIGURE  TUG  & SC  C0R  SERVICE  OP'J 
TAKE  ENG,,NG  DATArSUSPECTED  MODULE^ 
PROVIDE  ASSISTS  BY  MANIPULATOR 
DEACTIVATE  SC  MODULES 
ACTUATE  SERVICER,  REPLACE  MODULES 
CHECK  CONTINUITY  op  MODULES 
ASSIST  WITH  MANIPULATOR  IP  NEEDED 
RECHECK  CONTINUITY  Ip  REOUIRED 
TAKE  PRAME  Oc  ENG  NG  DATA, 

REPORT  STATUS  TO  GROUND 

PREPARE  SPACECRAPT  PQR  DEPLOYMENT 


SERVICE  OPER. 


ION  I TOR  CRITICAL  PARAMETERS 
POSITION  CCTV  TO  OBSFRVE  DFPLOY , 
SPIN  UP  RFACTION  WHEELS  IP  REo'd, 
IDEPLOY  APPENDAGES  AS  POSSIBLE 
SWITCH  SC  TO  INTERNAL  POWER 
DISCONTINUE  TUG  S/S  SUPPORT  TO  SC 
CHECK  SC  RP  LINKS  TO  GROUND 
DROP  TUG-TO-SC  UMBILICALS 
|PERPORM  PARTIAL  CHECK  Oc  SC  SYST,  , 
PARTIAL  CHECK  OP  MISSION  EQUIPMENT? 
|SPIN  UP  SC  IP  NECESSARY 
TAKE  PRAME  Oe  SC  ENG'NG  DATA 
IVFRIPV  SC  READY  FOR  DEPLOYMENT 
TAKE  PRAME  OP  TUG  ENG'NG  DATA 
VERIpy  TUG  READY  FOR  DEPLOYMENT 
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(HOURS) 
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START 
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3 2.2  9 2 Prepare  Spacecraft  For  Servicing 

The  Spacecraft  is  prepared  for  servicing  concurrently  with  the  Tug  and  many 
of  the  descriptions  of  Tug  preparation  sub-events  in  3 2 2 9 1 apply  equally 
well  to  the  Spacecraft  preparations  As  soon  as  the  umbilicals  are  connected, 
the  critical  parameters  of  any  Spacecraft  subsystems  which  may  be  operating 
are  monitored  by  the  Tug  and  despmmng,  if  required,  is  performed  as  described 
previously  Thermal  conditioning  and  closed  circuit  television  inspection  of 
the  Spacecraft  by  the  Tug  are  also  as  described  earlier  Some  variability  may 
exist  in  the  combinations  of  Spacecraft  subsystems  which  are  already  active 
when  Spacecraft  servicing  preparations  begin  depending  on  whether  the  Standard 
Servicing  Module  was  entered  from  the  Standard  Payload  Placement  Module  or 
from  the  Standard  Docking  Module  and  therefore,  different  subsystems  may 
require  activation  Whichever  case  may  apply,  the  remaining  Spacecraft  sub- 
systems are  activated  If  required,  passivation  is  completed,  and  reaction 
wheels  are  braked  Early  in  the  sequence  of  events,  in  fact  when  critical 
parameters  have  been  first  monitored,  checkout  of  the  modules  to  be  replaced 
begins  After  all  of  the  modules  are  activated  and  checked,  a frame  of 
engineering  data  is  taken  for  reference  before  any  changes  are  made  Having 
verified  the  modules  to  be  replaced,  the  Spacecraft  subsystems  are  deactivated 
and  the  modules  to  be  replaced  are  unlatched  At  this  point  the  Spacecraft  is 
verified  as  being  ready  for  servicing  and  a status  report  is  sent  by  the  Tug 
to  the  ground  When  the  Standard  Service  Module  is  entered  from  the  Standard 
Payload  Placement  Module,  all  the  above  events  except  the  unlatching  of 
modules  may  have  been  performed  m SPPM  6,  "Checkout  Payload  (Spacecraft)"  and 
may  be  bypassed  in  SSM  2 

32293  Perform  Scheduled  Servicing  Operations 

Critical  parameters  are  monitored  during  servicing  to  the  extent  possible  with 
the  Spacecraft  subsystems  shut  down  and  the  closed  circuit  television  is 
positioned  to  observe  the  operation  of  the  Servicer  in  the  module  exchange 
activity  The  servicer  is  then  activated  to  exchange  the  modules  previously 
identified  for  replacement  Some  lattitude  exists  in  the  module  replacement 
definition  to  allow  for  various  servicing  approaches  which  may  call  for  manipu- 
lators or  indexing  rack  mechanisms  The  0 333  hour  time  allowed  for  module 
replacement  is  compatible  with  100%  replacement  of  modules  with  the  "rotating 
grid"  servicer  No  significant  reduction  in  module  exchange  time  is  realized  by 
changing  fewer  modules  down  to  50%  of  the  module  population  Some  reduction 
is  possible  if  fewer  than  50%  of  the  modules  are  exchanged  Following  replace- 
ment of  modules,  a continuity  check  is  conducted  and  a report  of  Spacecraft 
status  is  sent  to  the  ground  The  nominal  scheduled  servicing  operation  re- 
quires 0 5 hours 

3 2 2 9.4  Post-Service  Checkout  of  Spacecraft 

Upon  completion  of  scheduled  service,  the  Spacecraft  with  its  complement  of 
new  modules  is  checked  out  to  verify  that  the  malfunctions  which  required  the 
servicing  operation  have  been  cleared  This  starts  with  the  monitoring  of 
critical  parameters  to  identify  any  possible  jeopardy  to  the  Tug  caused  by  the 
operation  or  mere  presence  of  the  Spacecraft  Identification  of  such  a jeopardy 
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will  cause  a decision  to  jettison  the  Spacecraft  The  closed  circuit  television 
is  positioned  in  such  a way  as  to  allow  observation  of  malfunctions  such  as 
leaks,  failure  of  mechanical  apparatus  such  as  deployment  mechanisms  to  operate, 
or  signs  of  fire  or  explosion  Tug  subsystem  support  is  required  by  the  Space- 
craft for  operation,  these  provisions  are  verified  by  the  Tug  DMS  before  Space- 
craft subsystems  are  activated  for  test  When  the  required  conditions  are  met, 
the  Spacecraft  subsystems  are  activated  and  checked  out  by  the  Tug  DMS.  Mission 
equipment  modules  may  have  sensor  contamination  covers  which  are  opened  and 
closed  as  required  for  the  checkout  When  Spacecraft  subsystem  and  mission 
equipment  modules  have  been  verified,  the  closed  circuit  television  is  positioned 
in  turn  to  observe  each  of  the  retracted  appendages  such  as  booms  and  antennas 
while  the  retraction  mechanism  is  operated  to  the  extent  possible  in  the  docked 
condition  RF  links  are  established  and  verified  between  the  Spacecraft  and 
ground,  repositioning  the  Tug  if  necessary  for  Spacecraft  antenna  pointing 
Finally,  a frame  of  engineering  data  is  taken  to  make  a record  of  the  Tug  and 
Spacecraft  status  just  prior  to  deployment  and  a status  report  is  sent  to  the 
ground  where  a decision  is  made  to  reservice  or  deploy  the  Spacecraft  The 
entire  post  service  checkout  operation  takes  just  over  one  hour  to  complete 

32295  Perform  Unscheduled  Service  Operations 

Following  the  nominal  service  mission  sequence  of  events,  unscheduled 
maintenance  would  be  performed  if  the  post  service  checkout  described  in 
33394  showed  that  malfunctions  still  exist  In  this  case,  the  monitoring 
of  critical  parameters  continues  throughout  the  unscheduled  service  operations 
When  the  decision  has  been  made  as  to  what  service  is  to  be  performed,  the 
closed  circuit  television  is  positioned  to  observe  the  service  operations  or 
any  visible  effects  of  them  Subsystem  support  is  continued  to  the  Spacecraft 
and  the  Tug  and  Spacecraft  are  configured  for  service  operations  Engineering 
data  is  taken  to  identify,  verify,  or  narrow  down  the  cause  of  the  malfunction 
and  a frame  of  engineering  data  is  taken  on  any  module  which  is  planned  to  be 
replaced  Modules  to  be  replaced  are  deactivated  and  the  Servicer  is  operated 
to  substitute  new  modules  for  suspected  ones  Continuity  checks  are  made  to 
verify  connections  on  the  newly  replaced  modules  During  any  of  these  service 
operations  the  manipulator  is  used  under  television  monitoring  to  give  mechani- 
cal "assists"  if  needed.  When  continuity  checks  show  replacements  to  be 
connected  correctly,  the  replaced  modules  are  activated  and  checkout  out  by 
repeating  Event  SSM  4,  "Post  Servicing  Checkout1'  When  correct  operation  of 
the  Spacecraft  is  indicated,  a frame  of  engineering  data  is  taken  and  the  status 
is  reported  to  the  ground  If  Post  Servicing  Checkout  shows  that  malfunctions 
still  exist,  SSM  5 "Unscheduled  Service  Operations"  can  be  repeated  and  the 
flow  of  SSM  4 can  again  be  followed  to  verify  proper  operation 

32296  Prepare  Spacecraft  For  Deployment 

Monitoring  of  critical  parameters  continues  throughout  preparations  for  deploy- 
ment and  the  closed  circuit  television  is  positioned  to  monitor  the  observable 
deployment  events  At  this  time  in  the  sequence,  any  required  reaction  wheel 
spinup  is  accomplished  The  two  hour  allocation  for  reaction  wheel  spinup  is 
bypassed  if  not  required,  reducing  the  time  requirement  for  deployment  prepara- 
tions to  less  than  an  hour  The  television  is  positioned  to  observe  deployable 
appendages,  one  at  a time,  and  these  are  deployed  to  the  extent  compatible  with 
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continued  dock  to  Tug.  When  Spacecraft  checks  indicate  readiness  for  deployment, 
a switch  is  made  to  internal  power  and  operation  is  again  checked  Thermal  and 
subsystem  support  is  discontinued  to  the  Spacecraft  and  Spacecraft-to-ground  RF 
links  are  established  Tug-to-Spacecraft  umbilicals  are  dropped  and  a partial 
check  of  Spacecraft  subsystems  and  mission  equipment  is  made  by  RF  link  If 
spin-up  is  required,  it  is  performed  at  this  time  by  use  of  a rotation  of  the 
servicer  docking  mechanism  A frame  of  engineering  data  is  taken  and  the  Space- 
craft is  verified  as  being  ready  for  deployment  then  a frame  of  Tug  engineering 
data  is  taken  and  the  Tug  is  verified  as  being  ready  to  deploy  the  Spacecraft 
At  this  point,  the  Standard  Service  Module  exits  into  Event  9 of  the  Standard 
Payload  Placement  Module  which  performs  the  countdown  and  release  Subsequent 
events  in  the  SPPM  command  and  control  the  post  deployment  checkout  of  the 
Spacecraft  If  malfunctions  are  detected,  the  Spacecraft  can  be  recovered  using 
the  Standard  Docking  Module  functional  flow  and  repairs  can  be  made  according  to 
the  Standard  Service  Module  flow  which  follows  Event  5 of  the  Standard  Docking 
Module 

3 2 2 10  Orbiter  Retrieval 

The  retrieval  of  the  Tug  by  the  Orbiter  is  essentially  accomplished  with  the  Tug 
m an  attitude  hold  mode  with  capture  implemented  by  the  Orbiter  crew  The  pro- 
cedure is  the  reverse  of  the  deployment  sequence  with  the  exception  that  Tug 
systems  are  safed  rather  than  activated  at  the  conclusion  of  the  sequence 
Figure  3 2 2-10  illustrates  the  flow  of  major  functions  for  the  retrieval  of  the 
Tug  from  orbit  Table  3 2 2-10  lists  the  events  associated  with'this  activity 

3 2 2 10  1 Orbiter  Acquire  Tug  Telemetry 

The  Tug  will  enter  the  Orbiter  retrieval  mode  from  the  on  orbit  coast  mode 
where  it  has  been  waiting  for  Orbiter  retrieval  operations  to  be  initiated  The 
first  function  of  the  Orbiter  will  be  to  secure  RF  contact  with  the  Tug  to  insure 
continual  real  time  Tug  C&W  mformatioa  and  Tug  command  control  capability. 

3 2 2 10  2 Deactivate  Tug  Mam  Propulsion 

Prior  to  deactivation  of  Tug  propulsive  systems  the  TOC  and  Orbiter  crew  will 
concur  that  the  Tug  will  not  be  required  to  make  a propulsive  maneuver  to  assist 
in  Orbiter  retrieval  After  this  decision,  the  Tug  propulsive  system  will  be 
safed  by  dumping  both  Lox  and  LhL  Upon  completion  of  propellant  safing  the  Tug 
will  assume  the  retrieval  attitude  and  rendezvous  aids  will  be  activated  The 
TOC  will  verify  to  the  Orbiter  crew  that  the  Tug  and  payload  are  ready  for  re- 
trieval 

3 2.2  10  3 Maneuver  Orbiter  for  Intercept  and  Rendezvous 

The  orbital  intercept  maneuver  will  be  the  responsibility  of  the  Orbiter  and 
Orbiter  crew  The  Tug,  in  a safe  condition  ana  in  a prescribed  attitude  will 
loter  in  a fixed  attitude  The  TOC  will  continually  monitor  Tug  status  and  keep 

the  Orbiter  crew  informed  At  the  request  of  the  Orbiter  crew  and  with  TOC 

concurrence,  command  control  of  the  Tug  will  be  transferred  from  the  TOC  to  the 
Orbiter  crews 
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STANDARD  ORBITER  RETRIEVAL  MODULE 


Figure  3 22-10.  Standard  Orbiter  Retrieval  Module 
3 2.2  10  4 Prepare  For  Retrieval 

The  Orbiter  will  have  the  option  of  either  flying  around  or  command  a Tug  attitude 
change  to  visually  inspect  the  Tug  and  payload  if  desired.  The  Orbiter  will  be 
prepared  by  the  crew  for  retrieval  Included  in  these  activities  are  opening 
the  Orbiter  payload  bay  doors,  assuming  the  retrieval  alignment  attitude  and 
activating  the  RMS  and  docking  adapter  The  Orbiter  crew  will  receive  final 
concurrence  from  the  TOC  that  the  Tug  is  ready  for  retrieval. 

3 2 10  5 Tug  Retrieval 

Tug  retrieval  begins  with  the  extension  of  the  RMS  by  the  Orbiter  crew  and  the 
mating  of  the  RMS  with  the  Tug  When  RMS/Tug  mate  is  accomplished  the  Tug  APS 
will  be  automatically  deactivated  Checks  will  be  conducted  at  this  time  to 
verify  the  Tug  is  safe  for  retrieval.  The  Orbiter  crew  will  then  retract  the 
Tug  with  the  RMS  and  mate  and  secure  the  Tug  to  the  docking  adapter  (DA)  Next 
the  fluid  and  electrical  umbilicals  are  connected  and  hard  wire  communication 
between  Tug  and  Orbiter  verified  This  being  accomplished  the  Tug  RF  system 
will  be  deactivated  and  the  RMS  will  be  detached  and  stowed  The  Tug  will  then 
be  rotated  into  the  Orbiter  bay  by  the  docking  adapter  and  on  completion  of 
rotation  the  forward  latches  will  be  secured  Forward  umbilical  connections 
will  be  established  and  when  verified  secure,  Orbiter  electrical  power  Will  be 
transferred  to  the  Tug  With  this  complete  the  crew  will  safe  the  Tug  fuel 
cells  and  configure  the  Tug  and  Orbiter  bay  for  re-entry. 

3 2 2.10  6 Deorbit 

The  deorbit  sequence  will  be  accomplished  by  the  Orbiter  crew  with  the  Tug  in  a 
deactivated  and  safe  configuration  The  only  activity  by  the  Tug  during  this 
phase  will  be  the  maintenance  of  the  Tug  safe  condition  and  the  caution  and 
warning  data  from  the  Tug 
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table  322-10.  Standard  Orb  iter  Retrieval  Module 
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CT) 


STANDARD  ORBITER  RETRIEVAL  MODULE  (06) 

Retrieval  operations  begins  with  the  Space  Tug  awaiting  rendezvous  with  the  Space  ENTRY 

Shuttle  and  terminates  with  the  return  of  the  Orbiter  to  Earth  EXIT 


On  Orbit  Coast 

Post  Landing  Ground  Control 


EVENT  DESCRIPTION 

EVENT  NUMBER 

EVENT 

DURATION 

(HOURS) 

EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 

ORBITER  ACQUIRE  TUG  TM 

01  00 

00  167 

- 0 267 

0\  ORBIT  NAVIGATION  MODE 

01  01 

TUG/ORBITER  RF  TM  LINK  ESTABLISHED 

01  02 

00  167 

- 0 267 

DEACTIVATE  TUG  MAIN  PROPULSION 

02  00 

00  100 

- 0 100 

VERIFY  TUG  PROPULSION  SYSTEM  NOT 

02  01 

00  017 

- 0 067 

NEEDED  FOR  TUG/ORBITER  RENDEZVOUS 

COMMAND  TUG  RETRIEVAL  SAFING 

02  02 

00  050 

- 0 050 

SEQUENCE  (LOX  DUMP  L«2  DUMP) 

MONITOR  AND  VERIFY  TUG  SAFE 

02  03 

00  050 

- 0 050 

COMMAND  RETRIEVAL  ATTITUDE 

02  OA 

00  017 

- 0 033 

VERIFY  ATTITUDE  AND  ATTITUDE  HOLD 

02  05 

00  017 

- 0 017 

VERIFY  TUG  READY  FOR  RETRIEVAL 

02  07 

00  017 

REF 

MANEUVER  ORBITER  FOR  INTERCEPT 

03  00 

00  350 

Orbiter 

Functions 

DETERMINE  RANGE  AND  RANGE  RATE 

03  01 

00  067 

DETERMINE  INTERCEPT  MANEUVERS 

03  02 

00  033 

COMPUTE  TPI  BURN  PARAMETERS 

03  03 

00  050 

MANEUVER  TO  TPI  BURN  ATTITUDE 

03  OA 

00  133 

PERFORM  TPI  BURN  (OMS  ENGINES) 

03  05 

00  017 

PERFORM  COURSE  CORRECTION  OPS 

03  06 

00  050 

MANEUVER  ORBITER  FOR  RENDEZVOUS 

OA  00 

00  184 

DETERMINE  RANGE  AND  RANGE  RATE 

OA  01 

00  067 

COMPUTE  TPF  BURN  PARAMETERS 

OA  02 

00  050 

ORIENT  ORBITER  FOR  TPF  BURN 

OA  03 

00  050 

VERIFY  ORBITER  READINESS  FOR  BURNS 

04  04 

00  050 

PERFORM  TPF  BURNS  (OMS/APS) 

OA  05 

VERIFY  TUG  SAFE  FOR  DOCK 

OA  06 

00  050 

ESTABLISH  ORBITER  RF  TUG  COMMAND 

OA  07 

(ORBITER  CONTROL) 

PREPARE  FOR  RETRIEVAL 

05  00 

00  167 

TUG  ATTITUDE  HOLD  MODE 

05  01 

00  167 

ORBITER  INSPECTION  OF  TUG 

05  02 

00  067 

ORBITER/TUG  RETRIEVAL 

05  03 

00  100 

ALIGNMENT  (ORBITER) 

PAYLOAD  BAY  DOORS  OPEN 

05  OA 

00  033 

ORBITER  CONFIGURED  FOR  RETRIEVAL 

05  05 

EVENT 
START 
TIME  IN 
MISSION 
(HOURS) 


Reference  Time 


Event  time  in  minutes 
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Table  32 2-10  Standard  Orbiter  Retrieval  Module  (Continued) 


STANDARD  ORBITER  RETRIEVAL  (06)  (CONTINUED) 


EVENT  DESCRIPTION 

EVENT  NUMBER 

EVENT 

DURATION 

(HOURS) 

EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 

TUG  RETRIEVAL 

06  00 

OO  617 

- 0 033 

RMS  EXTENDED 

00  033 

- 0 033 

RMS/TUG  MATE 

00  017 

REF 

TUG  APS  DEACTIVATED 

00  017 

0 033 

VERIFY  TUG  CONFIGURED  AND  SAFE  FOR 

06  04 

00  050 

0 050 

RETRIEVAL 

TUG  RETRACTION  BY  RMS 

06  05 

00  083 

0 100 

TUG /DA  MATE 

06  06 

00  050 

0 167 

DA  FLUID  AND  ELECTRICAL 

06  07 

00  017 

0 233 

CONNECTIONS  ESTABLISHED 

TUG/ORBITER  HARDWIRE 

06  08 

00  017 

0 250 

COMMUNICATION  VERIFIED 

TUG  RF  OFF 

06  09 

00  017 

0 267 

RMS  DETACHED  AND  STORED 

06  10 

00  017 

0 283 

TUG  CONFIGURED  FOR  DA  ROTATION 

06  11 

00  017 

0 300 

TUG  ROTATED  INTO  ORBITER  BAY 

06  12 

00  050 

0 317 

FORWARD  LATCHES  ENGAGED 

06  13 

00  017 

0 367 

UMBILICALS  CONNECTED 

06  14 

00  017 

0 383 

ELECTRICAL  POWER  TRANSFER 

06  15 

00  017 

0 400 

TUG  FUEL  CELLS  OFF 

06  16 

00  017 

0 400 

PAYLOAD  BAY  DOORS  CLOSED 

06  17 

00  033 

0 417 

TUG  SYSTEMS  CONFIGURED 

06  18 

00  050 

0 450 

FOR  RE-ENTRY 

PAYLOAD  BAY  CONFIGURED  FOR 

- 06  19 

00  100 

0 500 

RE-ENTRY 

DEORBIT 

07  00 

Orbiter 

Functions 

PERFORM  DEORBIT  COAST  OPERATIONS 

07  01 

PERFORM  DEORBIT  MANEUVERS 

07  02 

PERFORM  ENTRY  AND  DESCENT  MANEUVERS 

07  03 

PERFORM  APPROACH  AND  LANDING 

07  04 

■ 

EVENT 
START 
TIME  IN 
MISSION 
(HOURS) 


In  deriving  a specific  abort  timeline  for  a mission,  the  time  of  abort  is  com- 
pared to  the  time  brackets  noted  for  each  abort  mode,  enabling  selection  of  the 
applicable  abort  mode  This  mode  is  followed  through  the  logic  paths  of  the 
overall  functional  flow  thus  identifying  those  major  events  which  apply  and 
their  timing  sequences.  The  abort  time  within  the  mission  is  then  taken  as 
the  reference  time  for  the  beginning  of  the  major  event  sequence  Times  within 
the  mission  for  each  applicable  major  event  and  its  sub-events  are  then  cal- 
culated by  adding  times  within  the  module  to  the  mission  time  at  which  abort  is 
initiated  Finally  the  appropriate  numerical  prefixes  are  added  to  the  event 
and  sub-event  numbers  to  fix  the  Abort  Module  in  the  overall  sequence  of  modules 
for  the  miss-ion  of  interest. 

3 2 2 11  Abort  Module 

The  Shuttle  System  provides  intact  abort  capability  throughout  all  mission 
phases  Definition  of  the  Orbi terj External  Tank  abort  modes  has  been  simplified 
by  the  assumption  that  a failure  of  Tug/SC  will  not  necessitate  an  Qrbiter/ET 
abort  This  assumption  is  validated  by  the  Tug/SC  design  requirement  which 
prevents  any  single  failure  of  Tug  or  Spacecraft  from  injuring  flight  personnel 
or  damaging  the  Orbiter  or  other  payloads  This,  in  combination  with  the  speci- 
fied capability  of  the  Orbiter  to  dump  hazardous  fluids  and  pressurants  overboard 
within  the  time  constraints  imposed  by  an  abort  situation,  relieves  the  Shuttle 
System  of  urgency  in  responding  to  Tug/SC  abort  requirements  Nevertheless, 
the  sequence  of  events  m a Tug/SC  flight  abort  timeline  is  strongly  influenced 
by  the  functional  status  of  the  Shuttle  System  elements  when  the  need  for  a 
Tug/SC  abort  is  identifed  Except  for  pre-launch  aborts,  which  are  not  covered 
in  this  study,  all  possible  combinations  of  Shuttle  System  element  status  are 
covered  by  only  four  abort  modes 

• Return  to  Launch  Site  (RTLS) 

• Abort  Once  Around  (AOA) 

■ Abort  to  Orbit  (ATO) 

t Abort  From  Orbit  (AFO) 

Since  all  of  the  flight  abort  modes  have  commonality  in  functional  requirements, 
some  of  the  major  functions  and  events  can  be  shared.  Therefore,  a single 
functional  flow  has  been  structured  for  the  Standard  Abort  Module  which  can  be 
entered  and  exited  in  such  a way  that  all  four  abort  modes  can  be  accomplished 
by  various  combinations  of  its  seven  major  functions  and  events  These  are 
distinguished  m Figure  3 2.2-11  by  the  darkened  outlines.  Boxes  with  the 
lighter  outlines  in  the  Standard  Abort  Module  functional  flow  illustrate  points 
of  entry  and  exit  and  references  to  interfaces  with  other  standard  timeline 
modules.  Notice  that  the  rendezvous  and  retrieval  functions  of  the  Standard 
Retrieval  Module  form  a part  of  Standard  Abort  Module  functional  flow  for  the 
Abort  From  Orbit  mode 
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Figure  3JJ-1 1.  Standard  Abort  Module 


The  seven  major  events  are  further  defined  in  Table  3 2 2-11  with  event  number, 
sub-event  descriptions,  time  duration,  and  start  time  within  the  module  Rela- 
tive timing  relationships  between  events  and  sub-events  is  illustrated  in  bar 
chart  form  Notes  on  the  bar  chart  show  times  within  the  mission  sequence  when 
each  of  the  four  abort  modes  applies 

3 2 2 11  1 Initiate  Configuration  of  Tug/SC  For  Retrieval 

A Tug/SC  abort  initiated  any  time  after  separation  from  the  Orbiter  necessitates 
rendezvous  and  docking  before  the  sequences  shared  by  the  other  abort  modes  can 
begin  This  required  rendezvous  and  docking  sequence  has  been  defined  in  the 
Standard  Orbiter  Retrieval  Module  for  the  operational  retrieval  and  deorbit  of 
the  Tug/SC  and  is  therefore  used  as  shown  in  Figure  322-11  for  the  second  major 
functional  sequence  in  the  Abort  From  Orbit  mode  Since  the  entry  point  to  the 
Standard  Orbiter  Retrieval  Module  is  "Orbiter  Acquire  Tug  TM",  the  abort  functions 
occurmg  between  identification  of  the  abort  requirement  and  Orbiter  acquisition 
of  Tug  TM  are  defined  in  "Initiate  Configuration  of  Tug/SC  for  Retrieval",  which 
is  labeled  "Event  1.0"  m the  Standard  Abort  Module.  When  the  need  for  Tug/SC 
abort  is  identified,  the  Tug  is  commanded  (sub-event  1 01,  Table  3 2.2-11)  to 
monitor  and  transmit  subsystem  status  data  to  the  ground  or  to  the  Orbiter  if 
it  is  in  the  vicinity  Next,  the  Tug  is  commanded  by  the  Orbiter  or  ground  as 
applicable  to  assume  and  hold  an  attitude  suitable  for  thermal  and  communica- 
tions purposes,  while  awaiting  the  rendezvous  and  retrieval  functions  When 
attitude  stability  has  been  achieved,  non-essential  subsystems  and  equipment 
are  shut  down  by  command  from  the  Orbiter  or  ground  as  applicable  and  critical 
parameters  are  monitored  until  conditions  permit  the  retrieval  operation  to 
begin  as  defined  in  Section  3 2 2 10,  "Orbiter  Retrieval",  continuing  up  to  the 
point  of  Tug/SC  deactivation  and  safmg,  the  entry  point  for  the  second  major 
event  (Abort  2)  of  the  Standard  Abort  Module 

3 2 2 11  2 Deactivate  Tug/SC  And  Return  To  Safe  Status 

Once  the  Tug/SC  is  aboard  the  Orbiter,  the  Abort  From  Orbit  sequence  can  follow 
the  same  functional  path  as  the  Abort  Once  Around  or  Abort  to  Orbit  modes, 
"Deactivate  Tug/SC  and  Return  to  Safe  Status"  which  is  major  event  two  in  the 
Standard  Abort  Module  When  abort  is  initiated  any  time  in  the  range  of  259 
to  373  seconds  after  launch,  the  Abort  Once  Around  mode  is  used  Between  the 
times  of  373  and  532  seconds,  the  status  of  the  Orbiter  and  Ground  is  such  that 
the  Abort  to  Orbit  mode  is  better  suited  to  the  circumstances  Whichever  of  the 
3 modes  (AFO,  AOA,  or  ATO)  is  being  followed,  the  first  sub-event  is  monitoring 
of  caution  and  warning  If  Tug/SC  activation  and  checkout  is  in  process  at  the 
time  a decision  to  abort  is  reached,  this  activity  is  terminated  Next, 
the  Data  Management  System  (DMS)  aboard  the  Tug  sequences  the  passivation 
of  all  other  subsystems  (except  any  needed  for  propellant  dumping)  and  sends 
status  reports  to  Orbiter  and  Ground  as  applicable  This  event  exits  into  event 
(Abort  3) 

3 2.2.11  3 Activate  Tug  Propellant  Dump  System 

This  event  which  is  common  to  the  AFO,  AOA,  and  ATO  abort  modes  begins  with 
the  continued  monitoring  of  caution  and  warning  and  critical  parameters  Fluid 
system  venting  is  switched  from  zero  g to  positive  g venting  and  while  monitoring 
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Table  3 2.2- 1 1 Standard  Abort  Module 


STANDARD  ABORT  MODULE 

The  Abort  Module  defines  the  sequence 
of  potential  orbiter  abort 

of  Tug  events 

for 

the  mission  periods 

EVENT  DESCRIPTION 

EVENT  NUMBER 

EVENT 

DURATION 

{HOURS) 

EVENT 
START 
TIME  IN 
MODULE 
(HOURS) 

EVENT 
START 
TIME  IN 
MISSION 
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VERIFY  TUG/SC  SAFE  FOR  RETRIEVAL 

01 

00 
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000 
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050 

000 
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02 
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03 
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TUG  DMS  VERIFY  STATUS  OF  TUG/SC 

01 

06 
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083 
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05 

008 

083 
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01 

07 
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DEACTIVATE  TUG/SC  & RETURN  TO 

SAFE  STATUS 

02 

00 
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MONITOR  CRITICAL  PARAMETERS 

02 

01 
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108 
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Table  322-11.  Standard  Abort  Module  (Continued) 


STANDARD  ABORT  HODULE  (PACE  2 CONTINUED) 
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EVENT  DESCRIPTION 


COMPLETE  TUG  PROPELLANT  DUHP 

MONITOR  C4W  REPORT  TO  ORBITER/GNt 

DETECT  PROPELLANT  DEPLETION 

D“S  SEOUENCE  SAFE  SHUTDOWN  OF  DUMI 

stop  lo,AU>2  Abort  Pressurization 

CLOSE  DftAIN/DUHP  line 

OPEN  POSITIVE  G VENT 
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SAFE  TUC  FOR  LANDING 
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DMS  SEOUENCE  PRESSURIZATION  DOWN 
MAINTAIN  HELIUM  PURGEA.O?  & LH? 
maintain  lo2&LH2  Tank  HE  Pressurl zatlo 

MONITOR  STATUS  REPORT  TO  ORB  /CND. 


EVENT  NUMBER 
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ILAUNCH  PAD  ABORT 


08  01 
08  02 
08  03 
08  04 
.08  05 
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08  07 
08  08 
08  09 
08  10 
08  11 
.08  12 
08  13 
08  14 
08  15 
08  16 
08  17 
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the  propellant  system  status  through  the  data  link,  the  Orbiter  OMS  or  RCS 
engines  are  fired  to  settle  Tug  propellants  in  tanks  When  propellants  are 
settled,  the  abort  pressurization  system  pressurizes  propellant  tanks  as 
sequenced  by  DMS  Tug  status  is  monitored  continuously  and  relayed  to  ground 
stations 

3 2 2 11  4 Initiate  Tug  Propellant  Dump 

This  event  (Abort  4)  is  common  to  all  four  abort  modes  It  begins  with 
caution  and  warning,  and  critical  parameter  monitoring  when  implementing  the 
RTLS  abort  mode  or  continues  such  monitoring  which  was  already  begun  for  the 
AFO,  AOA,  and  ATO  abort  modes  When  propellant  tank  pressurization  is  complete, 
the  DMS  sequences  beginning  of  dumping  by  first  controlling  flow  to  a trickle, 
chilling  down  lines,  then  increasing  flow  to  a full  flow  condition  When  full 
flow  is  reached,  the  OMS  or  RCS  thrusting  begun  earlier  for  the  AFO,  AOA,  ATO 
abort  modes  is  terminated  completing  dumping  by  blowdown  Since  the  Orbiter 
engines  are  still  operating  at  time  of  RTLS  abort,  the  forward  thrust  supports 
dumping  During  the  dumping  operation  the  DMS  momtors-Tug  status  which  is 
provided  to  the  Orbiter  for  relay  to  the  ground  stations 

3.2.2  11  5 Complete  Tug  Propellant  Dump  And  Return  To  Safe  Status 

This  event  (Abort  5),  which  applies  only  to  the  AFO,  AOA,  and  ATO  abort  modes, 
continues  the  monitoring  of  caution  and  warning,  and  critical  parameters.  When 
sensors  detect  propellant  depletion  in  LH?  and  LQ2  tanks,  the  DMS  sequences  the 
shutdown  of  tank  pressurization,  the  closing  of  drain  and  dump  lines,  and  the 
beginning  of  helium  purge  for  entry  and  landing.  Throughout  this  event  the 
DMS  continues  to  monitor  Tug  status  which  is  provided  to  the  Orbiter  for  relay 
to  the  ground  This  event  exits  into  event  7 of  the  Standard  Orbiter  Retrieval 
Module,  “Deorbit". 

3 2 2 11  6 Complete  Tug  Propellant  Dump 

This  event  applies  only  to  the  RTLS  abort  mode  and  takes  advantage  of  the 
inpulse  provided  by  the  continuing  main  engine  burn  to  complete  propellant 
dumping  Monitoring  of  caution  and  warning,  and  critical  parameters  continues, 
and  specifically,  tank  sensors  detect  propellant  depletion.  When  depletion 
is  indicated,  the  DMS  sequences  the  halting  of  the  dump  process  by  stopping 
L02  and  LFL  abort  pressurization,  closing  drain/dump  lines,  and  opening  the 
positive  g^vent  A backup  program  m the  Orbiter  DMS  acts  as  a backup  to 
sequence  the  termination  of  the  dump  operation  safely.  Instrumentation  and  the 
DMS  monitor  vehicle  status  which  is  provided  to  the  Orbiter  for  relay  to  the 
ground 

3 2 11  7 Safe  Tug  for  Landing 

This  event,  which  applies  only  to  the  RTLS  abort  mode  continues  the  monitoring 
of  caution,  warning,  and  critical  parameters  The  DMS  sequences  safmg  of  the 
L02  and  LH2  propellant  system  and  the  abort  pressurization  system  and  controls 

the  LQ?  and  LH?  helium  purge  to  the  transport  pressure.  Instrumentation  and 
the  DMS  monitor  vehicle  status  which  is  provided  to  the  Orbiter  for  relay  to 
the  ground  This  event  exists  into  Event  7 of  the  Standard  Orbiter  Retrieval 
Module,  "Deorbit", 
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SPACE  TUG  CONFIGURATION  DESCRIPTION 


A baseline  Space  Tug  configuration  was  provided  by  NAS A/MS FC  as  a basis  for 
the  operational  and  costing  analyses  required  in  the  study  effort.  This 
section  gives  an  overview  of  the  subsystems  and  operational  configurations 
for  the  Space  Tug  The  baseline  configuration  was  derived  from  the  infor- 
mation included  in  References  No  1 and  No  16. 

4 1 OVERALL  TUG  DESCRIPTION 

The  Space  Tug  is  30  feet  long  and  14  2/3  feet  in  diameter  and  consists  of  LH2 
tank,  a LCL  tank,  a RL-10  derivative  IIB  main  engine  with  an  extendable 
nozzle,  ana  a body  shell  made  up  of  a forward  skirt,  main  skirt  and  aft 
adapter  The  basis  Tug  configuration  is  shown  in  Figure  4.1  0-1  The  Tug 
includes  a hydraulic  system  for  activator  control,  a termal  control  system, 
a helium  bottle  system  for  purging,  pressurization  and  valve  control,  an 
auxiliary  propulsion  system,  and  an  avionics  system  The  avionics  include 
the  following  subsystems 

• Data  Management 

• Guidance,  Navigation  and  Control 

• Rendezvous  and  Docking 

• Electrical  Power  and  Distribution 

• Communications 

• Measurement 

The  Tug  '(and  deployment  adapter)  wet  weight  is  approximately  58,600  pounds 
with  a Tug  dry  weight  of  approximately  5100  pounds 

4 2 STRUCTURAL  SUBSYSTEM 

The  following  is  a summary  of  the  structural  elements  of  the  Tug  and  their 
basic  function 

• Forward  Skirt  - supports  the  payload,  docking  mechanism,  non-pro- 
pul si  ve  vent  system,  and  a portion  of  the  avionics  The  forward 

Tug/Spacecraft  structural  support  attachment  allows  the  deployment 
and  retrieval  of  Spacecraft 

t Main  Skirt  - supports  the  LQ?  and  LFL  tanks,  four  APS  thruster 
packages,  3 hydrazine  tanks,  helium  Dottles,  selected  avionics 
including  the  fuel  cells,  and  various  umbilical s , panels  and  platforms. 

• LH2  and  L02  Tanks  - provide  the  storage  for  Space  Tug  propellants. 

t LHp  and  L0p  Tank  Supports  - provide  structural  support  for  the 

LH2  and  L02  tanks 
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• Thrust  Structure  - provides  engine  interface  structure 

• Thermal  Insulation  - provides  thermal  protection  and  micrometeriod 
protection 

• Deployment  Adapter  - provides  Orbiter  interface  structure  including 
Tug  latching  system,  umbilical  plates,  and  propellant  dram  and 
dump  The  adapter  is  used  to  pivot  and  rotate  the  Tug  from  the 
Orbiter  payload  bay  during  deployment 

• Tug/Orbiter  Umbilicals  - provides  vent  and  propellant  lines,  the 
purge  and  electrical  interfaces  connections  between  Tug  and  Orbiter 

4 3 PROPULSION  AND  MECHANICAL  SUBSYSTEMS 

The  following  is  a summary  of  the  propulsion  and  mechanical  subsystem  com- 
ponents and  pertinent  operational  characteristics  baselined  for  the  Space 
Tug  vehicle 

431  Main  Engine 

The  baseline  engine  is  the  Pratt  and  Whitney  RL-IO  Derivation  I IB  with  thrust 
levels  of  15,000  lbs,  for  major  AV  maneuvers  and  3,750  lbs  for  small  AV 
maneuvers  A retractable  nozzle  is  extended  after  Orbiter  deployment  and 
retracted  prior  to  recovery  by  electric  motor  driven  screw  jacks  Normally 
closed  prevalves  are  present  in  both  the  fuel  and  oxidizer  lines  to  prevent 
propellant  from  reaching  the  engine  until  it  is  desired  The  engine  requires 
application  of  pneumatic  and  electrical  power  and  a start  signal  to  initiate 
its  start  sequence  The  engine  is  stopped  by  removal  of  the  start  signal 
and  rendered  safe  by  removal  of  penumatic  and  electrical  power.  Five  failures 
(two  valves,  pneumatic  and  electric  power  application  and  start  signal)  would 
be  required  to  inadvertently  fire  the  engine 

432  Propellant  and  Pressurization 

The  propellant  feed,  fill  and  drain  system  configuration  is  shown  in  Figure 
4 3 2-1  The  propellant  feed  system  consists  of  the  valves  and  ducting 
between  the  propellant  tanks  and  the  engine  pump  inlets  The  propellant 
fill,  drain  and  dump  consists  of  the  valves  and  ducting  the  Tug/Orbiter/ 
external  interfaces  and  the  propellant  tanks  The  LH2  feed  line  doubles  as 
the  fill  and  drain  system  Prevalves  are  located  in  the  LH2  feedlmes  to 
isolate  the  propellant  tanks  from  the  engine  and  to  act  as  redundant  feed 
system  valves  in  combination  with  the  engine  inlet  valves  The  LO2  fill 
system  contains  dual  fill  and  drain  valves  to  provide  redundancy  for  critical 
dump  operations  during  a launch  abort  No  redundancy  is  provided  for  any 
system  beyond  the  “fail  safe"  mode 

The  pressurization  system  provides  tank  pressurant  for  main  engine  requirements 
and  for  engine  pneumatic  requirements  The  system  schematic  is  shown  in 
Figure  4 3 2-2  Helium  is  used  for  tanks  pressurization  and  mamstage 
pressurization  is  provided  by  GH2  and  G02  tapoffs  on  the  main  engine  Redun- 
dancy is  provided  in  the  regulation  of  both  the  L02  pressurization  and  the 
pneumatic  system  Two  regulators  in  parallel  protect  against  the  failed 
closed  regulator  mode,  a shutoff  valve  in  each  leg  protects  against  the  failed 
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Figure  4 32-1  Space  Tug  Propellant  Feed,  Fill  and  Dram  System 
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MIL 


open  mode,  and  relief  valves  in  series  protect  against  system  over-pressuri- 
zation  or  loss  of  helium  due  to  leakage  Control  of  GHg  and  GCL  flow  from 
the  main  engine  tapoff  will  be  by  single  non-redundant  solenoid^val ves 

The  vent  system  provides  the  control  devices  for  tank  venting  during  propellant 
loading  and  to  prevent  tank  over-pressurization  The  system  schematic  is 
shown  in  Figure  4 3 2-3  The  primary  vent  systems  are  functional  during 
loading,  ascent  and  positive  acceleration  periods  The  secondary  tank  vent 
system  vents  the  LH2  and  L02  tanks  during  periods  of  zero  or  low  acceleration 
Redundnacy  in  both  the  LO2  and  LH2  systems  is  provided  through  the  use  of 
dual  valving  Each  vent  valve  has  its  own  pneumatic  control  valve -so- that- 
valve  interdependence  is  eliminated  _ 

The  propellant  loading  and  monitoring  system,  shown  in  Figure  4 3 2-4,  provides 
propellant  mass  indications  during  loading  and  powered  flight  Propellant 
mass  signals  are  supplied  to  the  Tug  telemetry  system  for  continuous  monitor- 
ing of  propellant  masses  during  burns  or  propellant  setting  maneuvers  During 
coast  periods,  mass  readings  are  not  a true  indication  of  the  propellants 
onboard  Low  level  point  sensors  are  included  in  each  tank  to  provide  engine 
cutoff  to  protect  the  propulsion  system  against  a depletion  shutdown 

433  Hydraulics 

The  hydraulic  system  provides  vehicle  attitude  control  in  pitch  and  yaw  during 
mamstage  operation  by  directing  the  main  engine  thrust  vector  It  is  a 
closed  loop  system,  receiving  commands  from  the  Tug  onboard  computer,  to  pro- 
vide the  required  gimballing  control  signals  Several  components  are  employed 
to  provide  performance  information 

• A flight  control  feedback  transducer  monitors  actuator  movement  and 
transmits  the  closed-loop  feedback  (error)  signals 

• A position  switch  indicates  a preset  reservoir  fluid  volume  level 

• A thermal  switch,  mounted  on  the  main  pump  manifold,  shuts  off  the 
auxiliary  pump  when  return  fluid  temperature  exceeds  a 'preset  level 

• A temperature  transducer  monitors  a return  fluid  temperature. 

• Low  and  high  pressure  transducers  monitor  return  fluid  and  operating 
fluid  pressures  for  performance  records 

9 A differential  transducer,  coupled  to  each  actuator  assembly, 
monitors  the  difference  in  pressure  between  each  side  of  the 
actuator  for  performance  records. 

434  Auxiliary  Propulsion  System  (APS) 

The  auxiliary  propulsion  system  is  shown  schematically  in  Figure  4 3 4-1  The 
APS  provides  for  three  axis  attitude  control  and  translation  capability  by 
using  four  clusters  of  six  thrusters  located  at  90°  intervals  around  the 
stage  Each  thruster  produces  25  lbs  thrust  Normal ly-open  isolation 
valves  are  located  at  the  inlet  to  each  cluster  of  thrusters  and  each  thruster 
’ is  equipped  with  series  redundant  propellant  valves  The  APS  design  also 
includes  relief  and  vent  valves  to  protect  against  tank  over  pressurization 
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Figure  4.3J-3  Space  Tug  Vent/Rehef  System 


Figure  4 33-4.  Space  Tug  Propellant  Loading  and  Monitoring  System 


Figure  4 3.4-1.  Space  Tug  Integrated  Hydrazine  APS 
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435  Thermal  Conditioning  System 

Space  Tug  avionics  thermal  control  is  provided  in  the  forward  skirt  by  radiation 
shields,  heaters  and  heat  pipes,  while  the  intertank  electronics  require  only 
heat  pipes  for  temperature  stabilization 

The  fuel  cells  use  an  active  thermal  conditioning  system  shown  schematically 
in  Figure  4 3 5-1  for  heat  dissipation  It  should  be  noted  that  the  use  of 
the  new  technology  lightweight  fuel  cells  could  reduce  the  heat  dissipation 
requirements  The  system  uses  a coolant  circulated  by  redundant  pumps  through 
space  radiators,  selector  valves,  a temperature  mixing  valve,  and  a- fuel  cell 
heat  exchanger  Dual  redundant  modulating  flow  control  valves  regulate  the 
amount  of  coolant  flowing  through  the  radiator.  The  accumulator  is  pres- 
surized with  helium  through  a normally-open  solenoid  vajve  and  pressure 
regulator  A relief  valve  is  provided  to(  prevent  excessive  pressure  buildup 
in  the  accumulator 

4 4 AVIONICS  SUBSYSTEM 

Ther  baseline  avionics  system  used  for  the  study  was- derived  mainly  from  the 
December,  1974,  GDC  Avionics  presentation  (Reference  No  1)  The  avionics 
are  divided  into  five  major  subsystems  as  shown  in  Fjgure  4 4 0-1  Two  - 
autonomy  levels  were  included  in  the  costing  exercise,  but  the  only  avionic 
difference  was  an  increase  in  software  for  onboard  targeting  for  Level  II 
autonomy. 

441  Avionics  Overview 

A system  block  diagram  of  the  proposed  baseline  Space  Tug  avionics  is  shown 
in  Figure  4 4 1-1  and  its  associated  equipment  list,  including  weight,  power 
and  volume  summaries  are  shown  in  Table  4 4.1-1  A typical  installation 
layout  of  the  Tug  avionics  is  shown  in  Figure  4 4 1-2  Basically,  the  system 
includes* a central  computer  with  data  bus  and  terminals  for  data  acquisition, 
distribution  and  onboard  processing  The  Tug  interfaces  with  the  GSE,  Orbiter 
and  Spacecraft  Guidance  and  navigation  sensors  provide  for  attitude  reference 
navigation  and  attitude  update  capability.  Communications  capability  allows 
RF  interface  with  the  Orbiter  and  ground,  while  the  rendezvous  and  docking 
elements  allow  the  capability  for  the  retrieval  of  Spacecraft  Fuel  cells 
provide  the  basic  power  generation  capability  for  the  Tug 

The  redundancy  for  Tug  subsystems  is  shown  in  Table  4 4 1-2  This  table 
also  includes  the  function  of  each  subsystem  and  the  components  or  subsystems 
critical  to  mission  success 

The  following  sections  include  a brief  summary  of  the  avionic  subsystems  and 
their  flight  operations  related  characteristics 

442  Data  Management  Subsystem 

The  data  management  subsystem  of  the  Tug  is  the  major  integrating  element  of 
the  avionics,  controlling  the  data  processing  and  data  control  for  all  Tug 
avionic  subsystems  The  major  components  of  the  DMS  can  be  seen  in  Figure 
4 4 0-1  and  4 4 1-1  The  DMS  is  a dual  redundant  system  consisting  of  fault 
tolerant  memory  modules  with  a translator,  central  processor  units  (CPU's), 
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Figure  4.3.5-1.  Space  Tug  Fuel  Cell  Thermal  Control  System 
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Figure  4. 4. 0-1.  Space  Tug  Preferred  Baseline  A vionics  System 
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Figure  4.4 . 7-7.  Space  Tug  Avionics  Updated  Baseline 


Table  4.4.1  -1.  Space  Tug  Avionics  Equipment  List 


EQUIPMENT 

NO. 

REQ 

ENVELOPE 

DIMENSIONS 

UNIT 

WEIGHT 

UNIT 

POWER 

(WATT) 

SUB 

SYSTEM 

WEIGHT 

(LB) 

DATA  MANAGEMENT  • 

100 

DIGITAL  COMPUTER 

(1) 

10 

14 

9.5 

34 

60 

CIU 

(2) 

5 

5 

6.5 

6.5 

7 

DIU 

(8) 

5 

5 

6.5 

5 

5 

TAPE  RECORDER 

(1) 

10 

8 

5 

13 

20 

GUIDANCE  NAVIGATION  & CONTROL 

190 

INERTIAL  MEAS  UNIT 

(1) 

9x9  DIA 

25 

100 

IMU  ELECTRONICS 

(1) 

10 

20 

5 

30 

100 

— rateTGyrSs 

Tii 

10 

10 

6 

20 

100 

STAR  TRACKER 

(2) 

6 

8 

12 

16 

12 

SUN  SENSOR 

(2) 

6.9 

6.5 

3 

4.5 

5 

CONTROL  ELECTRONICS 

(1) 

12 

12 

18 

50 

50 

ILT— ANTS./RECEIVER 

(1) 

12 

10 

9 

24 

15 

RENDEZVOUS  & DOCKING 

• 

63 

SCANNING  LADAR 

(1) 

6 

8 

20 

28 

10 

& ELECTRONICS 

(1) 

9 

9 

11 

11 

30 

TV  CAMERA  & ELECTRONICS 

(2) 

6 

6 

15 

8 

10 

TV  STROBE  LAMPS 

(4) 

3.5 

3.5 

3.5 

1 

STROBE  ELECTRONICS 

(2) 

2 

3.5 

2.5 

2 

COMMUNICATIONS 

149 

ELEC  STEERED  PHASED  ARRAY 

(3) 

3.5  x 15  IN.  DIAM 

16 

93 

OMNI  ANT/NETWORK/SWITCH 

(1) 

5 

5 

6 

11.3 

3 

TRANSPONDER 

(2) 

15 

7 

6 

16.5 

16 

SIGNAL  PROCESSOR 

(2) 

13.5 

6 

6.5 

11 

18 

COMMAND  DISTRIB 

(1) 

5 

5 

4 

18 

35 

SGLS ENCRYPTER 

(2) 

6 

4 

5 

4.3 

7 

SGLS DECRYPTER 

(2) 

6 

4 

5 

4 

2.5 

INSTRUMENTATION 

74 

TRANSDUCERS 

(243) 

20 

— 

SIGNAL  CONDITIONERS 

(3) 

12 

10 

6 

18 

22 

ELECTRICAL  POWER.  DIST  & CONTR 

322 

FUEL  CELLS  POWERPLANT 

(2) 

12 

6 

15 

42 

20 

EMERGENCY  BATTERY  (150  AH) 

(1) 

8 

11 

7 

36 

- 

PWR  DISTRIBUTION 

46 

- 

PWR  PROCESSING 

(2) 

9 

9 

8 

8 

- 

HARNESSES/SWITCHES/M  ISC 

140 

• 

AVIONICS  SYSTEM  WEIGHT  898  LB 

ORIGINAL  PAGF  re 
°F  POOR 
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Figurt  4.4. 1-2.  Typical  Space  Tug  Avionics  Installation  Layout 
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Table  4.4. 1-2.  Tug  Operational  Redundancy  Summary 


COMPONENT/SUBSYSTEM 

REDUNDNACY 

BACKUP 

FUNCTION 

**IMU 

2 Failures 
Tolerant 

— 

Inertial  Reference 
(with  DMS) 

Rate  Gyros 

2 Failures 
Tolerant 

— 

Flight  Control  Aid 

ILT 

1 Channel 

Ground 

Navigation  Update 

Star  Trackers ) 
Sun  Sensors  j 

1 Spare 
Each 

— 

Attitude  Update 

**DMS 

Dual  Redundant 

— 

On-Board  Processing 
and  Control 

**Fuel  Cells 

Dual  Redundant 

Battery 

Power  Generation 

Laser  Radar 

— 

Ground, 

LLLTV 

Rendezvous  with  Payload 

***LLLTV 

Dual  Redundant 

— 

Docking  with  Payload 

Communications 

Dual  Redundant 

— 

Orbiter,  Ground  Interface 

♦♦Auxiliary  Propulsion 
System 

Basically 

Redundant 

— 

Attitude  Control,  Low 
Level  Thrust 

♦♦Main  Propulsion 
System 

Some  Simplex 
Some  Redundant 

— 

High  Energy  Thrust 

♦♦Systems  Mandatory  for  Tug  Operation 
♦♦♦LLLTV  Mandatory  for  Tug  Docking  with  Payloads 


input/output  processor  (IOP),  computer  interface  units  (CIU's),  data  busses, 
digital  interface  unit  (DIU's)  and  a tape  recorder.  Present  computer  sizing 
includes  48K  of  32  bit  memory  with  a speed  requirement  of  over  400  KOPS 
during  burn  phases.  The  computer  software  provides  for  all  navigation, 
guidance  and  control  processing,  onboard  components  redundnacy  management, 
telemetry  processing  (CIU),  rendezvous  and  docking  computations  and  sequenc- 
ing for  all  Tug  subsystems.  The  following  gives  a brief  description  of  each 
component. 

4.4.2. 1 Main  Memory 

The  main  memory  is  baselined  as  a semi-conductor  memory  with  high  speed,  low 
weight,  low  cost  and  high  reliability.  The  memory  has  internal  fault  tolerant 
characteristics  which,  in  conjunction  with  the  translator,  provides  error 
checking  and  corrections  in  the  event  of  malfunction.  Spare  bit  planes 
replace  malfunctioned  bit  planes  when  errors  are  detected.  Forty-eight  K 
of  32  bit  memory  is  baselined. 

4. 4. 2. 2 CPU/IOP/CIU 

The  CPU  provides  the  onboard  processing  capability  for  the  Tug  with  a speed 
requirement  of  about  400  KOPS.  The  IOP  controls  the  input  and  output  operations 
to  the  CPU  and  with  the  ClU/data  bus  and  processes  the  IMU  input  data.  The 
CIU  controls  the  data  bus  and  provides  the  formatting  for  telemetry.  These 
components  operate  in  a prime/backup  mode  with  bit  and  self-test  providing 
the  indications  of  failure  and  when  backup  mode  are  implemented. 

4. 4. 2. 3 Data  Bus/DIU 

The  data  bus  system  has  two  bus  lines,  command  and  reply,  which  are  twisted 
shielded  pairs  and  operate  at  a 2 MBPS  rate.  Four  DIU's  (eight  with  redun- 
dancy) are  baselined  and  these  provide  the  interface  with  all  Tug  and 
Spacecraft  subsystems  requiring  process  support  or  providing  data  for 
telemetry/ record.  Redundant  DIU's  are  cross-strapped  to  each  component  to 
provide  a fail  safe  path  to  all  components.  The  use  of  the  data  bus,  DIU's 
and  CIU  provide  and  integrate  telemetry  provided  by  other  hardware  on  previous 
space  programs. 

4. 4. 2. 4 Tape  Recorder 

The  tape  recorder  is  used  to  record  data  for  maintenance  purposes,  especially 
during  main  engine  burn  phases.  The  recorder  is  baselined  for  100  megabits 
of  storage  and  has  a read  capability  to  allow  playback  of  data  through 
telemetry  when  ground  conmuni cations  are  available. 

4.4.3  Guidance,  Navigation  and  Control  (GN&C)  Subsystem 

The  basic  hardware  elements  of  the  GN&C  subsystem  and  their  functions  are  as 
follows: 

• Laser  IMU  - inertial  reference 

• Interferometric  Landmark  Tracker  (ILT)  - state  vector  update 
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• Star  Tracker  and  Sun  Sensors  - attitude  update 

• Laser  Rate  Gyros  - flight  control  sensor 

The  guidance,  navigation,  and  control  computations  are  performed  in  the  onboard 
digital  computer  using  input  data  provided  from  the  above  sensors  and  feed- 
backs from  the  control  elements.  The  baseline  components,  including  software 
elements,  are  shown  in  Figure  4. 4. 3-1.  The  following  gives  a brief  description 
of  the  GN&C  components  and  their  functions. 

4. 4. 3.1  Inertial  Measuring  Unit  (IMU) 

The  IMU  is  a laser  gyro  dodecahedron  which  provides  the  capability  for  proper 
operation  even  after  two  gyro  and  two  accelerometer  failures.  The  onboard 
digital  computer  maintains  the  attitude,  velocity  and  position  states.  Vehicle 
movements  are  detected  by  the  IMU  and  its  outputs  are  sent  to  the  computer  for 
continuous  state  vector  and  attitude  computations.  The  IMU  software  includes 
the  compensation  and  failure  detection  capability  required  for  the  IMU,  and 
some  limited  BITE  capability  is  available. 

4. 4. 3. 2 Interfermetric  Landmark  Tracker  (ILT) 

The  ILT,  shown  schematically  in  Figure  4. 4. 3-2,  uses  four  antennas  receiving 
the  same  ground-generated  radar  signal  to  provide  data  to  the  computer  for 
state  vector  update  computations.  Time  phase  differences  between  the  input 
signals  to  the  four  ILT  antennas  are  used  to  determine  the  direction  of  the 
generating  radar  station  and  subsequent  software  comparisons  provides  data 
for  the  required  update.  Since  only  three  channels  are  required  for  proper 
operation,  the  fourth  channel  provides  redundancy  to  accommodate  one  failure. 

An  injected  RF  signal  can  be  used  for  closed  loop  verification  of  proper  ILT 
operation. 

4. 4. 3. 3 Star  Tracker  and  Sun  Sensor 

The  star  trackers  and  sun  sensors  provide  the  required  onboard  capability  for 
autonomous  attitude  updates.  One  star  tracker  and  one  sun  sensor  are  operated 
simultaneously  to  provide  the  complete  attitude  orientation  information 
required.  Both  sensors  are  dual  redundant,  and  provide  a light  source  for 
self-test  capability.  Sensor  redundancy  management  and  sensor  data  processing 
is  provided  by  the  computer. 

4. 4. 3. 4 Rate  Gyros  and  Flight  Control  Electronics 

The  Tug  computer  provides  the  thrust  vector  and  attitude  control  commands  and 
monitors  error  signals  for  proper  vehicle  control  and  maneuvers.  The  thrust 
vector  control  systems  uses  triple  redundant  servoampl ifiers  driving  triple 
redundant,  voting  servoactivators  for  main  engine  positioning.  The  laser 
rate  gyros  in  a dodecahedron  configuration  provide  for  inputs  to  the  control 
law  equations  to  aid  the  flight  control  functions.  The  computer  manages  the 
rate  gyro  redundancy. 
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Figure  4.4.3-1.  Space  Tug  Baseline  GN&C  Subsystem 
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Figure  4.4.3-2.  Space  Tug  Interferometric  Landmark  Tracker  (IL  T) 
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4 4 4 Communication  Subsystem 

The  communication  subsystem,  shown  in  Figure  4 4 4-1,  consists  of  three  25 
element  phased  array  antenna  systems  which  provide  integrated  tracking, 
telemetry  and  command  interface  capability  with  the  Orbiter  and  ground.  The 
system  has  provisions  for  both  directional  steering  and  omnidirectional 
capabilities  The  communications  interface  with  the  Tug  is  also  shown  on 
Figure  4 4 4-1  The  system  is  essentially  dual  redundant  for  all  subsystem 
components  The  communications  will  be  activated  during  the  Tug  deployment 
sequence  and  deactivated  during  the  recovery  operations 

445  Rendezvous  and  Docking  Subsystem 

The  rendezvous  and  docking  subsystem  presently  baselines  a scanning  laser  radar 
(SLR)  for  the  rendezvous  with  Spacecraft  and  a low-1 ight-level  TV  (LLLTV) 
for  remote  man-in-the-loop  docking  with  Spacecraft  The  LLLTV  is  also  used 
for  visual  inspection  of  Spacecraft 

The  SLR,  as  shown  in  Figure  4 4 5-1,  in  conjunction  with  the  Tug  DMS  provides 
the  capability  for  autonomous  rendezvous  with  Spacecraft  The  SLR  provides 
range  and  angle  data  to  the  DMS,  which  provides  the  proper  maneuver  commands 
to  achieve  rendezvous  to  within  approximately  30  feet  of  the  target.  Only  a 
single  SLR  is  baselined  for  the  Tug,  however,  the  ground  tracking  plus  the 
LLLTV  can  be  used  to  accomplish  the  rendezvous  in  the  event  of  a SLR 
malfunction 

The  LLLTV  with  a man-in-the-loop  is  the  proposed  candidate  for  docking  with 
the  Spacecraft  and  for  visual  inspection  A block  diagram  of  the  proposed 
system  is  shown  in  Figure  4 4 5-2  This  shows  the  camera,  lights  and  elec- 
tronics for  the  TV  system  as  well  as  the  ground  interface  and  Tug  computer 
support  required  for  the  docking  operations  The  LLLTV  system  is  dual 
-redundant  In  the  event  malfunction  of  both  systems,  no  backup  capability  is 
available  for  docking 

As  shown  in  Figure  445-2,  an  extensive  ground  interface  with  continuous 
ground  communications  is  required  for  the  docking  operations  This  would 
be  a ground  interactive  system  with  ground  commands  controlling  the  Tug 
operation  based  on  input  data  supplied  by  the  LLLTV,  and  this  is  a major 
impact  on  flight  control  operations. 

4 4 6 Electrical  Power  Subsystem 

The  electrical  power  subsystem  consists  of  dual  redundant  fuel  cells  which 
generate  power  for  the  Tug,  and  emergency  battery  for  contingency  operations, 
distribution  and  control  components.  A new  technology  lightweight  fuel  cell 
is  baselined  The  Tug  power  subsystem  is  dual  redundant  with  automatic  and 
DMS  control  provided  in  the  subsystem 

The  Orbiter  provides  power  to  the  Space  Tug  during  all  phases  when  the  Tug  and 
Orbiter  are  attached  The  Space  Tug  fuel  cells  will  be  activated  during 
prelaunch  to  supplement  the  Orbiter-provided  power  during  Orbiter  ascent  and 
burn  phases  The  Orbiter  power  will  be  disconnected  just  prior  to  Tug 
deployment  and  reconnected  after  retrieval 
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25  ELEMENT  PHASED  ARRAY  ANTENNAS 


Figure  4 4 4-1  Space  Tug  Baseline  Communications  System 
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Figure  4.4  5-1.  Rendezvous  and  Docking  Subsystem  Autonomous  Go  As  SLR  Ctndidete 
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Figure  4 4 5-2  Rendezvous  and  Docking  Subsystem  Man-ln-The-Loop  Candidate 


447  Measurement  Subsystem 

A Space  Tug  measurement  subsystem  was  designed  to  provide  signal  conditioning 
and  measurements  for  the  Tug  Approximately  200  total  measurements  were 
baselined  for  the  Tug  and  these  are  summarized  in  Table  4 4 7-1.  For  opera- 
tional analysis  for  the  Tug,  it  was  assumed  that  approximately  60  C&W  and 
safety  related  parameters  and  40  subsystem  status  related  parameters  were 
provided  to  the  Orbiter  during  attached  and  proximity  operations  The 
measurement  system  interfaces  directly  with  the  Dill's  for  input  to  and  pro- 
cessing by  the  Tug  DMS  The  measurements  are  processed  by  the  DMS  and  routed 
as  telemetry  to  communication  link  (or  Orbiter  hardware  interface)  as  required 


Table  4 4 7-1  Tug  Measuring  System  Parameters 


ENGINE 

STAGE 

Temperature 

5 

Temperature 

15 

Pressure 

7 

Pressure 

20 

Position 

4 

Vibration 

15 

Speed  (RPM) 

1 

Flow 

2 

Vibration 

1 

Position 

20 

Other 

6 

Voltage 

36 

24 

Liquid  Level 

12 

Depletion  Sensors 

1 7 

Strain 

20 

H2  Leak  Sensors 

8 

02  Leak  Sensors 

8 

Gas  Analysis 

3 

Contamination 

10 

176 
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SPACE  TUG  OPERATIONAL  INTERFACE  ANALYSIS 


The  Space  Tug  operational  interfaces  required  analysis  to  determine  their 
capability  as  they  related  to  mission  operations  This  was  done  by  analyzing 
the  baseline  requirements  as  defined  in  Section  2 0 to  determine  what  various 
interfaces  were  required  to  accomplish  Systems  capabilities  were  then 
analyzed  on  both  sides  of  all  interfaces  This  was  possible  in  varying  depths 
depending  upon  stages  of  development  With  requirements  and  interfacing 
system  capabilities,  the  interfaces  could  be  defined  in  terms  of  mission 
operations  to  determine  adequacy  and  further  define  mission  operations  It 
was  an  iterative  process,  building  upon  improved  definition  to  better  the 
understanding  of  the  problem  and  to  improve  the  solution  The  parallel 
studies  were  used  heavily  to  define  the  Tug,  the  Spacecraft,  the  Tug  inter- 
faces, and  the  operational  requirements 

JSC's  documentation,  mainly  Volume  XIV  Space  Shuttle  System  Payload  Accom- 
modations Rev  C thru  change  7 was  used  heavily  to  define  the  Shuttle 
accommodation  for  the  payloads,  in  this  case  the  Tug 

Tug  Operational  Interface  Definition  - The  Space  Tug  interfaces  with  the 
Orbiter,  the  Spacecraft  (payloads),  the  Ground  Support  Equipment  (GSE)  and 
the  Tug  Operations  Center  (TOC)  for  flight  operations  interfaces  One  or 
more  of  these  interfaces  are  available,  although  not  always  continuously,  for 
mission  phases  from  prelaunch  operations  through  deployment,  payload  replace- 
ment/retrieval , Orbiter  retrieval  and  landing  operations  The  interfaces 
provide  the  operational  data  exchange  for  the  various  phases  required  for 
flight  operations  and  flight  control  Figure  5 0 0-1  shows  the  Tug  data 
interfaces  during  preflight  operation,  and  the  Tug  data  interfaces  after 
liftoff  during  all  phases  that  the  Tug  and  Orbiter  are  attached  Figure 
5 0 0-2  shows  the  Tug  data  interfaces  during  flight  phases  when  the  Tug  and 
Orbiter  are  detached  This  section  will  discuss  the  Tug  data  interfaces 
(Spacecraft/Orbiter  interfaces  not  included)  and  the  types  of  data  exchange 
required  for  each  interface.  The  interfaces  shown  are  a combination  of 
Orbiter  and  ground  support  capabilities,  Tug/SC  data  requirements  and  the 
design  implementation  used  by  the  Tug  and  SC 

5 1 TUG/ORB  ITER  INTERFACE 

The  Tug/Orbiter  interface  received  the  most  attention  because  it  is  the  most 
active  (time  and  volume  of  data  exchanged)  It  is  also  the  most  urgent  to 
define  because  of  potential  design  impacts  to  the  Orbiter 

511  Orbiter  Payload  Interface  Support 

The  Orbiter  provides  a wide  variety  of  interface  capability  for  the  varying 
payloads  to  be  carried  Figure  5 1 1-1  gives  an  overview  of  the  avionic 
interfaces  available  for  payloads,  such  as  the  Tug,  and  the  associated  paths 
for  the  data  As  shown,  the  Orbiter  provides  interfaces  for  the  following 
types  of  data  which  are  useful  to  the  Tug 

• Engineering  Data  - 16  KBPS  to  the  Payload  Siqnal  Processor  (PSP) 
and  up  to  5 channels  of  up  to  64  KBPS  each  multiplexed  through 
the  Payload  Data  Interleaver  (PDI) 


5-1 


ee 

SB 

ff 

e| 

{tel 


51, 


Nj 


F'9urs  5 0 0-1  Tug  Operational  Interfaces  - Tug/Orbiter  Attached 
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TUG/ORBITER  COMMUNICATIONS  LIMITED  TO  TUG  WITHIN  20  NM  OF  ORBITER 

THERE  ARE  NO  ACTIVE  INTERFACE  REQUIREMENTS  BETWEEN  THE  TUG  AND 
SPACECRAFT  AFTER  SPACECRAFT  SEPARATION 


Figure  5 0 0-2  Tug  Post-Deployment  Operational  Interfaces  - Tug/Orbiter  Detached 
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Figure  5.1,1 -1  Orb  iter  A v to  rues  Functional  Diagram  for  Payloads 


• Command/Data  Input  - 2 KBPS  (8  KBPS)  command  link  from  the  PSP,  GN&C 
data  to/from  the  Tug  and  discretes  from  the  Multiplexer/Demultiplexer 
(MOM) 

• Caution  and  Warning  - input  capability  for  hardwire  C&W  signals 
to  the  C&W  Electronics  Unit 

• Timing  - timing  signals  from  the  Orbiter  Master  Timing  Unit  (MTS) 

In  additional,  high  data  rate  interfaces  are  available  for  scientific  data 
not  required  for  the  Tug,  but  may  be  used  by  the  Spacecraft  (SC) 

The  Orbiter  has  allocated  approximately  10K  of  32  bit  words  in  main  storage 
and  approximately  18  KOPS  for  payload  (Tug/Spacecraft)  support  in  its  general 
purpose  computer 

The  Mission  Specialist  Station  (MSS)  and  Payload  Specialist  Station  (PSS) 
also  have  space  available  for  Tug  dedicated  interface  panels  See  Figure 
5 1 1-2  which  shows  potential  placement  of  non-standard  avionics  to  support 
Tug  operations  Figure  5 1 1-3  gives  typical  layouts  of  the  control  display 
panel  in  the  Orbiter  which  will  support  the  Tug  operations  As  shown,  these 
C&D  interfaces  include  status,  deploy  operations.  Tug  commands,  abort 
sequences  and  manual  control  of  Tug  elements 

512  Tug/Orbiter  Interface  Overview 

5121  Prelaunch/Fl lght 

The  Tug/Orbiter  prelaunch  and  flight  data  interfaces  are  summarized  in  the 
right  half  of  Figure  5 0 0-1  and  include  all  mission  phases  when  the  Tug 
and  Orbiter  are  physically  attached  The  Orbiter  provides  IRIG  B timing 
signals  to  the  Tug  from  its  master  timing  unit  Ground  commands  (2  KBPS) 
to  either  the  Tug  or  Spacecraft  are  routed  through  the  Orbiter  Payload  Signal 
Processor  (PSP)  and  relayed  to  the  Tug  command  decoder  Tug  commands  are 
processed  by  the  Tug  and  Spacecraft  commands  are  routed  to  the  Spacecraft 
for  execution 

The  Tug  and  Spacecraft  telemetry,  for  Orbiter  and/or  ground  use,  is  routed 
from  the  Tug  through  a multiplexer  in  the  Tug  Deployment  Adapter  (D/A)  to 
the  Orbiter  or  Payload  Data  Interleaver  (PDI)  This  link  contains  the  house- 
keeping/status data  required  to  evaluate  the  Tug  and  Spacecraft 

The  hardwire  data  links  between  the  Tug  and  Orbiter  provide  the  Caution  and 
Warning  (C&W)  signals  to  the  Orbiter  displays  through  the  C&W  system  and 
provide  a means  of  issuing  time-critical  safety  commands  The  1 MBPS  command/ 
monitor  link  is  routed  through  the  Deployment  Adapter  to  the  Orbiter  and 
provides  a means  of  obtaining  the  Tug  C&W  (backup)  and  safety  critical  para- 
meter (primary)  as  well  as  the  command  capability  to  execute  safety  related 
commands  as  required  In  addition,  this  1 MBPS  link  provides  the  Orbiter/ 

Tug  data  link  (through  the  D/A)  to  provide  data  required  by  the  Tug,  such  as 
a Navigation  Update,  and  to  receive  status  and  verification  data  required 
by  the  Orbiter  to  monitor  Tug  activities,  such  as  IMU  activation 
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It  is  assumed  that  a standardized  16  KBPS  link  will  provide  the  safety  and 
operational  data  required  by  the  Orbiter  for  both  attached  and  detached 
modules  For  standard  interface  this  link  would  be  routed  through  the 
Orbiter  PSP  If  it  is  found  that  more  than  16  KBPS  is  required  for  Orbiter 
and/or  ground  interface  while  the  Tug  and  Orbiter  are  attached  up  to  64  KBPS 
of  data  could  be  routed  through  the  Orbiter  PDI  for  Orbiter  use  or  for  S-Band 
transmission  to  the  ground  In  addition,  up  to  50  MBPS  could  be  routed 
through  the  Orbiter  Ku-Band  link  to  the  ground 

5122  Post-Deployment 

The  Tug/Orbiter  post-deployment  data  interfaces  are  shown  in  the  upper  right 
of  Figure  5 0 0-2  and  includes  the  deployment  and  retrieval  phases  when  the 
Tug  and  Orbiter  are  detached  and  within  20  NM  of  each  other  As  shown,  the 
only  data  interfaces  between  the  Tug  and  Orbiter  are  the  telemetry  and  command 
interfaces  which  include  both  Tug  and  Spacecraft  data 

The  telemetry  link  is  required  to  provide  Tug  and  Spacecraft  C&W,  safety 
related  and  status  data  to  the  Orbiter  to  determine  their  health  during 
deployment  and  retrieval  operations.  The  16  KBPS  RF  data  link  is  provided 
to  the  Orbiter  PSP  The  command  link  allows  the  Orbiter  to  control  safety 
critical  Tug/SC  parameters  during  near  vicinity  operations  and  to  provide 
backup  capability  for  critical  activation  signals  as  required 

513  Caution  and  Warning  Description 

The  caution  and  warning  implemented  in  the  Orbiter  for  safety  monitoring  of 
Tug  parameters  is  treated  here  for  completeness  of  the  Tug/Orbiter  interface 
analysis  To  summarize,  the  Orbiter  C&W  system,  as  it  interfaces  with  the 
Tug  as  a payload,  is  undefined  (TBD)  by  the  Orbiter  at  this  time  See 
Figure  5 1 3-1 
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Figure  5 1 3-1.  Current  C&W  Definition 


The  work  done  from  Orbital  Operations  point-of-view  is  summarized  below 


• The  Tug  safety  requirements  were  analyzed  in  Section  2 4 and  the 
"Tug  Operational  C&W  Status  Measurements  and  Annunciators) 
recommendations  appear  m Section  243 

• A complete  “Space  Shuttle  C&W  Definition  as  Related  to  Space  Tug1’ 
is  contained  in  Appendix  B of  this  volume. 

• The  Orbiter  definition  of  the  Payload  C&W  is  shown  in  Figure  b 1 3-1 
which  is  from  Change  No  7 to  JSC  Volume  XIV  Payload  Accommodations 
and,  therefore  is  its  current  definition  When  it  is  compared  to  the 
similar  Figure  3m  Appendix  B,  it  is  seen  to  be  now  accommodating  TBD 
C&W  parameters  for  payloads  and  is  also  now  pictured  a less  powerful  syste 

514  Tug/Orbiter  Operational  Interactions 

The  following  is  a summary  of  Space  Tug/Orbiter  operational  interactions 
(See  Table  5 1 4-1) 

The  Orbiter  monitors  the  Tuq  C&W  and  safety  related  parameters  to  assure 
Orbiter  crew  safety  and  provides  the  switching  capabilities  to  correct  any 
detected  malfunctions  These  safety  parameters  are  monitored  and  controlled 
while  the  Tug  is  in  the  cargo  bay  or  in  the  near  vicinity  of  the  Orbiter 


The  Orbiter  will  provide  the  capability  to  initiate  safety  or  deployment  critical 
functions  during  Tug  deployment,  and  will  monitor  the  results  of  those  actions  to 
assure  the  events  have  been  accomplished  The  critical  activation  items  include 
power  transfer,  IMU  and  communications  activation,  and  APS  activation  The  Orbiter 
will  control  all  mechanisms,  such  as  latches  and  umbilicals,  which  relate  to 
deployment 

The  Orbiter  will  monitor  the  status  of  safety  or  mission  critical  subsystems 
to  assure  mission  accomplishment,  however,  the  detailed  Tug  status  will  be  the 
prime  responsibility  of  the  ground  Corrective  commands,  which  are  not  safety 
critical,  will  be  issued  by  the  ground  and  routed  through  the  Orbiter  for  Tug 
malfunction  and  contingency  operations 

The  Orbiter  has  a similar  relationship  with  the  Spacecraft  while  attached  to 
the  Tug  C&W  monitors  and  controls  for  the  Spacecraft  are  available  in  the 
Orbiter  Spacecraft  wideband  data  is  sent  direct  to  the  Orbiter  not  thru  the 
Tug  Spacecraft  telemetry  and  RF  uplink  commands  are  sent  to/from  the  ground 
thru  the  Tug  and  Orbiter 

5 2 TUG  OPERATIONS  CENTER  (TOC)  INTERFACE 

The  Tug  RF  link  to  the  ground  and  return  link  provides  the  capability  for 
communications  with  the  Tug  Operations  Center  (TOC)  after  Tug  deployment  by 
the  Orbiter  This  interface  is  shown  in  Figure  5 0 0-2  and  may  be  relayed 
through  the  STDN  or  TDRS  to  the  TOC  The  command  link  provides  a 2 KBPS 
capability  for  operational  or  contingency  commands  to  either  the  Tug  or 
Spacecraft  while  they  are  attached  The  downlink  provides  status  and  opera- 
tional data  to  the  TOC  from  both  the  Tug  and  Spacecraft  The  downlink 
required  capability  is  16/64  KBPS  for  LLLTV  After  Spacecraft  separation, 
the  Spacecraft  will  provide  its  own  ground  interface  capability 
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Table  S 1.4-1.  Summary  of  Space  Tug/Orbiter  Operational  Interactions 


• Safety  Monitoring  and  Controls 

Tug  C&W/BU  c&W  (Pressures,  Temperatures,  Busses  Safe,  Bus  Power) 

Orbiter  Switches  to  Correct  C&W  Conditions 

q Tug  Activation,  Deploy,  Retrieval,  Safing  Monitoring  and  Controls 

Orbiter, Switches  to  Accomplish  Requirements  of  the  Above  Phases 
Feedbacks  to  Lights  Indicate  Tasks  Accomplished 

• Tug  Status  Monitoring  and  Commanding  (Largely  Fed  Thru  Orbiter  To/From  Ground 
Control ) 

Detailed  Tug  Status  (C/0)  Prime  Responsibility  of  Ground 
Contingency  Commanding  Possible  From  Ground 

• Spacecraft/Tug/Orbiter  Operational  Interactions  Similar  to  Many  of  the  Above 
Functions  in  Wide  Spectrum  Depending  on  Payload 

Spacecraft  Wideband  Data  Largely  Fed  Thru  Orbiter 

Spacecraft  TLM  To/From  Ground  Control 

Spacecraft  RF  Command  Uplink 
Spacecraft  C&W  and  Switches  to  Correct 
Conditions 


5 3 TUG/SPACECRAFT  INTERFACE 


The  Tug/Spacecraft  interface  exists  from  prelaunch  through  Tug/Spacecraft 
separation  and  are  shown  in  Figures  5 0 0-1  and  5 0 0-2  There  are  no  active 
Tug/Spacecraft  data  interfaces  after  their  separation  and  Tug/Spacecraft 
interfaces  for  SC  retrieval,  servicing,  spin/despin  have  not  been  defined 
at  this  time  Other  Spacecraft/Orbiter  and  Spacecraft/Ground  links  exist, 
but  are  not  included  in  this  study 

The  Tug/Spacecraft  command  and  telemetry  interfaces  essentially  routes  the 
required  Spacecraft  telemetry  and  command  data  to/from  the  ground  and/or 
Orbiter  This  interface  allows  SC  status  and  backup  C&W  signals  to  be  multi- 
plexed in  the  Tug  telemetry  stream  and  SC  commands  received  when  no  independent 
SC  communication  capability  exists.  The  amount  of  SC  telemetry  to  be  included 
in  the  Tug  16  KBPS  link  is  variable  up  to  10  KBPS 

Other  Tug/Spacecraft  data  links  provide  the  required  control /mom tor 
capability  for  the  Tug  to  perform  selected  SC  sequences  prior  to  separation, 
such  as  activation,  and  to  monitor  status  and  feedback  as  required. 

5 4 TUG/GSE  INTERFACE 

The  Tug/GSE  interface  is  active  during  the  prelaunch  operations  (see  Figure 
5 0 0-1)  and  during  post-landing  safing  Any  post-landing  data  interfaces 
in  addition  to  those  for  prelaunch  have  not  been  identified  in  this  study 

The  Tug/GSE  data  interfaces  (through  the  Deployment  Adapter  (D/A))  are  for  the 
Tug/SC  16  KPBS  link  which  contains  the  same  C&W,  safety  related  and  status 
data  provided  to  the  Orbiter  The  GSE  command/mom  tor  link  interface  (1  f'BPS) 
provides  2-way  communications  between  the  onboard  computer  and  the  GSE  (through 
the  D/A)  and  provides  the  capability  for  prelaunch  operations,  updates  or  status 
required  prior  to  liftoff 

5 5 TUG/DEPLOYMENT  ADAPTER  INTERFACE 

Telemetry  and  command/mom tor  data  links  exist  between  the  Tug1  and  the  Tug 
Deployment  Adapter  as  shown  in  Figure  5 0 0-1  These  links  are  routed 
from  the  Tug  Computer  Interface  Unit  (CIU)  to  the  D/A  MUX/DEMUX  which  routes 
data  to  the  Orbiter  and  the  GSE  The  functional  interface  between  the  Tug 
and  D/A  is  two  commands  from  the  Tug  to  the  D/A  for  use  during  abort  The 
Tug  and  Tug  D/A  separate  during  deployment  and  are  reattached- during  Tug1 
retrieval  operations 

5 6 TUG/ INTERSTAGE  ADAPTER  INTERFACE 

The  Tug/ Interstage  Adapter  interfaces  are  shown  in  Figures  5 0 0-1  and  5 0 0-2 
These  interfaces  are  to  provide  separation/pyrotechmc  commands  to  the 
separation  devices  and  to  monitor  their  status  The  capability  also  exists  - 
to  excite  the  adapter  instrumentation  transducers  and  to  monitor  the  corre- - 
spending  results  and  status  This  interface  is  active  during  the  Tug/SC 
separation  phase 


SPACE  TUG  DEPLOYMENT  AND  RETRIEVAL  OPERATIONS 

The  major  emphasis  in  the  area  of  Tug  deploy  and  retrieval  operations  was 
to  develop  the  Tug  on-orbit  checkout  requirements  This  was  done  by  first 
developing  a checkout  (C/0)  philosophy  and  then  implementing  if  found  con- 
sistent with  the  Tug  checkout  requirements  and  design 

6.1  ANALYSIS  OVERVIEW 

An  overview  of  the  Space  Tug  orbital  checkout  analysis  is  shown  in  Figure 
6 1 0-1 

6.1.1  Study  Purpose  and  Flow 

The  purpose  of  this  analysis  is  to  develop  a C/0  philosophy  consistent  with 
hardware  design  trends  and  requirements  The  philosophy  is  also  influenced 
by  goals  which  tended  to  maintain  analysis  direction  With  a defined  philos- 
ophy it  was  possible  to  develop  a checkout/mom  tori ng  summary  which  defines 
what  and  when,  and  is,  in  effect,  a timeline  The  checkout  functions  are  then 
assigned  to  establish  prime  and  backup  responsibility  Finally,  the  C/0 
software  resident  in  the  Orbiter  was  sized  to  provide  an  estimate  of  the  impact 
to  the  Orbiter  subsystems 

612  Definitions  of  Orbital  Checkout  Terms 


The  orbital  checkout  analysis  required  the  development  of  a definition  of 
certain  terms  because  of  their  varied  usage  A summary  of  the  definition  of 
orbital  C/0  terms  is  contained  in  Table  6 1 2-1  The  following  is  a descrip- 
tion of  the  most  ambiguous  terms 

• Status  Monitor  - This  is  the  routine  assessment  of  the  telemetry 
data  to  determine  system  status  It  is  basically  limit  checking 
of  voltages,  temperatures,  and  pressures 

• Checkout  - Extraordinary  effort  taken  to  determine  health  or  ability 
to  function,  such  as  applying  a command  or  a stimulus  and  noting 

the  reaction  compared  to  expectations 

• Operational  Monitor  - Monitoring  of  normal  operational  system  output 
to  be  compared  to  normal  timeline  operational  system  data  to  assess 
system  health 

• Activation  Monitor  - Monitoring  of  parameters  which  indicate  proper 
turn-on  to  the  best  step  by  step  detail  that  existing  telemetry 
measurements  will  allow 

• Prime  Responsibility  - This  is  the  designated  origin  of  test  or 
health  inquiry  per  operational  timeline  and  the  designated 
evaluator  of  results 

« Back-Up  Responsibility  - This  is  the' designated  back-up  who 
monitors  test  or  health  inquiry  per  operational  timeline  and 
reports  results  as  a back-up  or  check  Back-up  commanding  of 
the  test  may  be  done  also  as  a contingency. 
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Table  612-1  Summary  of  Definitions  of  Orbital  Checkout  Terms 


I STATUS  MONITOR  - ROUTINE  ASSESSMENT  OF  TM  STREAM  TO  DETERMINE  HEALTH- 

2.  CHECKOUT  - EXCEPTIONAL  EFFORT  TO  DETERMINE  HEALTH  OR  ABILITY,  IE.,  STIMULUS  RESPONSE. 

3.  OPERATIONAL  MONITOR  - MONITOR  OPERATIONAL  RESULTS  DURING  NORMAL  UP  TIMES  — DYNAMIC  MEAS. 

4 ' ACTIVATION  MONITOR  - MONITOR  RESULTING  TM  FROM  TURN-ON  PROCEDURES 

5 DEACTIVATION  MONITOR  - MONITOR  RESULTING  TM  FROM  TURN-OFF  PROCEDURES 

6 PRIME  RESPONSIBILITY  - INITIATES  TEST  OR  HEALTH  INQUIRY  PER  TIMELINE  AND  REPORTS  RESULTS. 

7 BACK-UP  RESPONSIBILITY  - MONITORS  TEST  OR  HEALTH  INQUIRY  AND  REPORTS  RESULTS  AS  A BACK-UP 

8 DYNAMIC  TESTING  - TESTING/MONITORING  DONE  IN  EVENT  OF  FAILURE  DETECTION 

9 BITE  - BUILT  IN  TEST  EQUIPMENT 

,10  PRE-DEPLOY  STATUS/CHECKOUT  - TUG  STATUS/CHECKOUT  REPORTING  TO  ENABLE  COMMIT  TUG  TO  DEPLOY 

II  * POST-DEPLOY  CHECKOUT'-  TUG  STATUS/ CHECKOUT  REPORTING  TO  ENABLE  COMMIT  TUG  TO  .MISSION 

12.  PRE-RETRIEVAL  CHECKOUT  - TUG  STATUS/ CHECKOUT  REPORTING  TO  ENABLE  COMMIT  TUG  TO  RETRIEVAL. 

13  POST-RETRIEVAL  CHECKOUT  - TUG  STATUS/CHECKOUT  REPORTING  TO  ENABLE  COMMIT  TO  DEORBIT  WITH. 
SAFE  TUG 


6 2 REQUIREMENTS,  GROUNDRULES  AND  ASSUMPTIONS 

The  requirements,  groundrules  and  assumptions  are  defined  to  clarify  the  basis 
for  this  analysis 

6.2  1 Space  Tug  Orbital  Checkout  Requirements  Assessment  Summary 

This  is  a summary  of  the  Space  Tug  orbital  checkout  baseline  requirements 
assessment,  contains  results  of  their  assessment,  and  incorporates  actions 
resulting  from  data  exchange  meetings 

The  requirements  are  categorized  into  two  mam  areas  implemented  and 
exceptions  The  category  of  implemented  is  further  divided  or  allocated  into 
area  of  responsibility.  The  implemented  and  allocated  requirements  are  those 
where  there  is  agreement  and  therefore  are  being  utilized  as  a basis  for 
Space  Tug  orbital  checkout  The  category  of  exceptions  consists  of  those 
requirements  where  there  is  not  agreement  and  exception  is  being  taken 
Rationale  is  given  for  the  exception 

6211  Baseline  Operational  Requirements  Implemented  and  Allocated 

The  following  requirements  are  those  where  there  is  agreement  and  therefore 
are  being  implemented  They  are  allocated  to  prime  and  back-up  responsibili- 
ties to  enable  specific  definitions  and  sizing  of  operational  impact. 

• Shuttle  Prime  Responsibilities 

Shuttle  will  monitor  Tug/Spacecraft  systems  during  all  flight 
phases  while  m cargo  bay 

Shuttle  will  hold  Tug  APS  inhibited  till  after  release  by  RMS. 
Shuttle  will  enable  Tug  APS 

Shuttle  will  disable  Tug  APS  prior  to  retrieval  or  for  mission 
termination 

Shuttle  will  monitor  Tug/SC  crew  safety  related  parameters 
during  near  vicinity  operations 

For  mission  abort,  crew  will  initiate  and  monitor  Tug  pro- 
pellant dump  prior  to  Tug  release 

Shuttle  will  monitor  Tug/SC  systems  to  ensure  safe  condition 
through  landing 

• Shuttle  Back-Up  Responsibilities 

Shuttle  crew  will  support  {upon  ground  request)  pre-deploy 
C/0 

• Ground  Control  Prime  Responsbilities 

Ground  controllers  will  verify  readiness  of  Tug/SC  for  deploy 
based  on  monitoring  Tug/SC  systems 
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Ground  controllers  will  verify  readiness  of  Tug/SC  for 
retrieval  based  on  monitoring  Tug/SC  systems 

Ground  controllers  will  maintain  detailed  status  of  Tug/SC 
systems  for  entire  mission 

t Ground  Control  Back-Up  Responsibilities 

Ground  control  will  provide  back-up  control  of  crew  safety 
functions 

• Tug  Prime  Responsibilities^ 

Redundancy  management  will  be  done  by  Tug 
Thru-put  checkout  results  from  SC 
6212  Baseline  Operational  Requirements Exceptions 

The  Space  Tug  orbital  checkout  baseline  requirements  were  reviewed  to  deter- 
mine any  potential  requirements  conflicts  with  projected  design  or  operations 
philosophies  The  exceptions  are  as  noted  with  rationale  given  for  each 

r 

• Requirement  Excerpt  From  Baseline  Flight  Operations,  Volume  3, 
Paragraph  361 

Tug/Spacecraft  Monitoring  and  Checkout  b.y  the  Shuttle 

"The  Shuttle  must  checkout  and  activate  the  Tug  attitude  hold 
systems  prior  to  remote  manipulator  system  (RMS)  release,  and 
inhibit  the  APS  until  after  release  is  accomplished  " 

Rationale  - APS  will  not  be  checked  out  prior  to  use,  system  consists 
of  series  of  valves  which  will  be  status  monitored  when  used 

• Requirement  Excerpt  From  Baseline  Flight  Operations,  Volume  3, 
Paragraph  4 3 14 

Tug/SC  Deploy 

"They  will  then  remove  the  Tug/SC  from  the  bay  and  deploy  it 
to  the  release  position  Then  under  control  of  the  crew  and 
monitored  by  the  crew  and  the  ground,  the  Tug  will  be  prepared 
for  release  After  ground  acquisition  of  Tug  signal,  and 
upon  receiving  affirmation  of  correct  configuration  from  the 
ground,  the  crew  will  release  the  Tug  and  stow  the 
mampulator(s)  " 


Rationale  - Ground  acquisition  of  Tug  signal  before  release  from 
KMS  will  not  be  affirmed  Deploy 'lighting,  antenna  pointing  and 
Orbiter  interface  constraints  make  exception  necessary 
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62.2  Groundrules  and  Assumptions 


The  following  groundrules  and  assumptions  were  made  to  bound  the  analysis  and 
to  capture  key  baseline  requirements  and  Tug  design  features  that  heavily 
influenced  the  task 

Tug  Checkout  Analysis  Groundrules  and  Assumptions 
t The  baseline  Tug  is  required  to  be  reusable. 

• The  baseline  Tug  is  Level  II  Autonomy 

• The  current  Tug  avionics  definitions  show  BITE  is  available  on  Tug 

• The  current  Tug  avionics  is  redundant  and  therefore  contains 

redundancy  management 

• The  baseline  Tug  is  operational  in  the  vicinity  of  the  manned 
Orbiter 

• The  analysis  includes  pre  and  post  deployment  and  retrieval  check- 
out, because  of  concern  with  Orbiter/Tug  operational  relationships. 

6 3 SPACE  TUG  REDUNDANCY  AND  SELF-TEST  SUMMARY 

The  fact  that  Space  Tug  is  designed  as  basically  a redundant  system  and  as 
baselined  Level  II  autonomy  it  must  provide  BITE  The  redundancy  level  was 
investigated  and  also  self-test  capability 

631  Tug  Operational  Redundancy  Summary 

Table  6 3 1-1  gives  a summary  of  the  major  Tug  components  (or  subsystems), 
the  redundancy  level  of  the  components,  any  backup  capability  available,  and 
the  function  of  the  component 

As  shown  by  the  asterisks  most  Tug  components  are  critical  for  mission  success, 
and  all  critical  system  are  redundant.  Redundancy  management  is  available 
onboard  consistent  with  baseline  autonomy  Level  II  Contingency  work-around 
will  be  possible  Orbital  operations  will  take  full  advantage  of  available 
redundancy  and  redundancy  management 

632  Space  Tug  Sensor  Checkout  Capability  Summary 

Table  6 3.2-1  shows  that  with  redundancy  management  software  utilizing  the 
checkout  capability -that  exists  for  the  Tug  components/subsystems  the  Tug 
will  be  largely  autonomous.  The  Orbiter  will  be  involved  mainly  in  safety 
related  status  and  contingency  back-up  The  ground  will  be  involved  mainly 
in  status  keeping  and  as  contingency  back-up  The  systems  mandatory  for  Tug 
operation  are  noted  with  asterisks 

6.4  CHECKOUT  GOALS  AND  PHILOSOPHY 

The  Space  Tug  on-orbit  checkout  goals  are  direct  results  of  application  of 
mission  operation  goals  to  this  particular  problem  The  Space  Tug  on-orbit 


6-6 


Table  631-1  Tug  Operational  Redundancy  Summary 


COMPONENT/SUBSYSTEM 

REDUNDANCY 

BACKUP 

FUNCTION 

*IMU 

2 Failures 
Tolerant 

— 

Inertial  Reference 
(with  DMS) 

Rate  Gyros 

2 Failures 
Tolerant 

— 

Flight  Control  Aid 

ILT 

X Channel < 

i 

Ground 

. 

Navigation  Update 

Star  Trackers 
Suo  Sensors 

1 Spare 
Each 

> 

1 Atti tude  Update 

*DMS 

Dual  Redundant 

— 

On-Board  Processing  and 
Control 

*Fuel  Cells  • 

j 

Dual  Redundant 

Batt 

v PoweY  Generation 

„ Laser  Radar 

— 

Ground,  “ 
LLLTV 

Rendezvous  with  Payload 

**LLLTV 

Dual  Redundant 

— 

Docking  with  Payload 

Communications 

Dual  Redundant 

— 

„>  Orbiter,  Ground  Interface 

*Auxiliary  .Pfopulsion 
System 

Basically 

Redundant 

— 

Attitude  Control, 
Low  Level  Thrust 

*Mai n " Propul s i on 
System  ’ 

Some  Simplex 
Some  Redundant 

p-_ 

High  Energy  Thrust 

v ' X 

*Systems  Mandatory  for' Tug  Operation 
**LLLTV  Mandatory  for  Tug  Docking  with  Payloads 


Table  6 3 2-1  Tug  Sensor  Checkout  Capability  Summary 


COMPONENT/SUBSYSTEM 

CHECKOUT  CAPABILITY 

STAR  TRACKER 

LIGHT  SOURCE  FOR  SELF-TEST 

SUN  SENSOR 

LIGHT  SOURCE  FOR  SELF-TEST 

ILT 

INJECTED  RF  SIGNAL  FOR  CLOSED  LOOP 
VERIFICATION 

*DMS 

INTERNAL  SELF-TEST  CAPABILITY 

*FUEL  CELLS 

BITE-CONTINUOUS 

SIGNAL  CONDITIONERS 

LIMITED  A/D  CONVERTER  CHECKS 

^ENGINE  CONTROL  ELECTRONICS 

FULL  END-TO-END  CHECKOUT  CAPABILITY 

*IMU 

PARTIAL  CHECKOUT  CAPABILITY  - QUICK  LOOK 

*SYSTEMS  MANDATORY  FOR  TUG  OPERATION 


checkout  philosophy,  summarizes  all  of  the  requirements  into  a workable  set  of 
rules  which  allow  systematic  addressing  of  the  problem 

641  Space  Tug  On-Orbit  Checkout  Goals 

The  goals  used  in  this  analysis  are  contained  in  Table  6411 

642  On-Orbit  Checkout  Philosophy 

The  major  emphasis  on  Tug  on-orbit  checkout  is  to  utilize  Tug  status,  activa- 
tion and  operational  data,  rather  than  interactive  checkout  results,  to 
determine  Tug  subsystem  status 

Some  components  are  activated  throughout  the  mission,  while  others  may  not 
be  required  for  all  mission  phases  To  conserve  power  and  enhance  reliability, 
subsystems  and  components  activated  after  deployment  should  be  checked  out  then 
Since  the  Tug  is  basically  autonomous,  sequences  will  be  initiated  and  con- 
trolled by  the  Tug  where  possible  _ No  nominal  mission  command  activity  is 
allocated  to  the  ground  and  only  safety  related  Orbiter  involvement  is 
required  after  deployment 

The  ground  will  monitor  all  telemetry  data  generated  by  the  Tug  for  status 
decisions  and  will  provide  commands  or  inhibits  only  if  onboard  malfunctions 
occur  It  will  report  safety  related  impacts  to  the  Orbiter  crew 

« 

The  Orbiter  will  monitor  and  control  safety  related  and  critical  subsystem 
parameters  and  will  initiate  some  activation  and  deactivation  sequences 
during  critical  phases,  such  as  deployment  and  retrieval.  It  will  provide 
backup  capability  to  the  ground  for  selected  Tug  subsystems 

The  Tug  will  initiate  and  control  all  Tug  sequencing  and  functions  which  do 
not  directly  impact  the  health  or  safety  of  the  Orbiter  and  its  crew 

The  major  items  in  the  Space  Tug  on-orbit  checkout  philosophy  are  contained 
in  Table  642-1 

6 5 PRE-DEPLOY  CHECKOUT  OPERATIONS 

The  purpose  of  pre-deploy  checkout  operations  is  clearly  stated  by  the 
following  definition 

PRE-DEPLOY  STATUS/ CHECKOUT  - TUG  STATUS/CHECKOUT  REPORTING  TO  ENABLE 
COMMIT  TUG  TO  DEPLOY 

6 5 1 Pre-Deploy  Component  Activations 

* •* 

Table  651-1  shows  the  activation/deactivation  sequence  recommended  for -Tug 
operations  As  shown  the  DMS  is  the  only  element  active  throughout ‘the  mission 
This  is  necessary  for  status  keeping  telemetry.  The  IMU  and  communications 
are  necessary  just  after  deployment,  therefore,  should  be  activated  when 
required 
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Table  6 4 1-1  Space  Tug  On-Orbit  Checkout  Goals 


• PROVIDE  OPERATIONAL  VERIFICATION  OF  TUG  PRIOR  TO  MAJOR  EVENTS 

• MAINTAIN  STATUS  OF  ALL  TUG  SUBSYSTEMS 

• MINIMIZE  ORBITER  INVOLVEMENT 

• COST  EFFECTIVE  UTILIZATION  OF  GROUND 

• MINIMIZE  POTENTIAL  ORBITER  SAFETY  IMPACTS 

t PROVIDE  COST  EFFECTIVE  APPROACHES  FOR  ON-BOARD  CHECKOUT 

• EFFECTIVE  USE  OF  TUG  ON-BOARD  CAPABILITIES  TO  SUPPORT  CHECKOUT 
AND  REDUNDANCY  MANAGEMENT 

• MINIMIZE  MISSION  TIMELINE  POTENTIAL  IMPACTS 
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Table  642-1  ^ ace  Tug  On-Orbit  Checkout  Philo  soph' 


• UTILIZE  TUG  STATUS,  ACTIVA-JION/DEACTIVATION  AND  OPERATIONAL  DATA  FOR  TUG 
SUBSYSTEMS  HEALTH 

« TUG  COMPONENTS/SUBSYSTEMS  ARE  NOT  ACTIVATED  UNTIL  REQUIRED  FOR  OPERATION 
<*  NO  PREPLANNED  COMMAND  ACTIVITY  ALLOCATED  TO  GROUND  CONTROL  (CONTINGENCY  ONLY) 

• NO  ORBITER  CHECKOUT  INVOLVEMENT  AFTER  DEPLOYMENT  AND  PRIOR  TO  RETRIEVAL 

• GROUND  INVOLVEMENT 

MONITORS' STATUS,  ACTIVATION/DEACTIVATION,  CHECKOUT  AND  OPERATIONAL  DATA 
PROVIDES  COMMANDS  OR  INHIBITS  IF  ONBOARD  TUG  MALFUNCTIONS  OCCUR 

• ORBITER  INVOLVEMENT 

MONITORS  C&W,  SAFETY  AND  CRITICAL  SUBSYSTEM  PARAMETERS 
CONTROLS  DEPLOYMENT  AND  RETRIEVAL  OPERATIONS 

INITIATE  SOME  ACTIVATION/DEACTIVATION  AND  BACKUP  SEQUENCE  INITIATION 
COMMANDS 

• TUG  COMMANDS  ALL  NON-C&W/ABORT  TUG  SEQUENCING 
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Table  6 5. 1-1.  Tug  Major  Component  Activation/Deactivation  Sequence 


4 

DEPLOYMENT 

' RETRIEVAL 

COMPONENT /SUBSYSTEM 

PRE-DEPLOY 

POST-DEPLOY 

j PRE -RETRIEVAL 

POST-RETRIEVAL 

DMS 

X 

X 

1 X 

X 

I MU 

ACTIVATE 

X 

1 X 

DEACTIVATE 

ELECTRICAL  POWER 

X 

X 

* X 

DEACTIVATE 

COMMUNICATIONS 

ACTIVATE 

X 

* X 

DEACTIVATE 

APS 

ACTIVATE 

1 DEACTIVATE 

MAIN  PROPULSION 

ACTIVATE 

DEACTIVATE 

GN&C  UPDATE  SENSORS 

ACTIVATE 

DEACTIVATE 

RENDOCK  SENSORS 

ACTIVATE 

| DEACTIVATE 

X = PREVIOUSLY  ACTIVATED 

1 

652  Pre-Deployment  Flight  Operations  Functional  Allocation 

Table  6 5 2-1  shows  the  major  flight  operations  activities  to  be  performed 
for  the  Tug  pre-deployment  and  the  allocation  of  functions,  either  prime  (X) 
or  backup  (B/U)  The  functions  include  the  on-orbit  operations- prior  to 
deployment 

During  the  pre-deptloyment  phase,  the  Orbiter  is  prime  for  safety  related 
functions  and  for  functions  related  directly  to  deployment  -Therefore,  as 
shown,  most  activities  during  the  deployment  phase  are  controlled  by  the 
Orbiter 

As  shown,  the  Tug  is  prime  for  IMU  activation  and  sequencing  which  would 
not  affect  the  crew  safety,  while  the  ground  is  prime  only  for  monitoring  ' 
functions  The  qround  is  also  backup  for  contingency  operations 

6 5 3 Checkout/Momtoring  Summary 

- 1 f 

Table  6 5 3-1  indicates  the  primary  types  of  data  gathered  for  Tug  status 
evaluation  for  the  various  mission  phases  As  shown,  status  and  operational 
data  are  the  primary  means  for  health  determination  when  the  components  are 
active 

For  components  which  are  activated  on  orbit,  limited  status  data  (either 
measurement  or  lack  of  measurement)  is  available  prior  to  being  activated, 
activation  data  is  available  during  component  turn-on,  and  operational  data 
available  after  activation 

The  Tug  IMU  and  Orbiter  state  vectors  will  be  compared  after  initialization 
to  determine  if  Tug  navigation  and  attitude  updates  are  required.  The  proper 
operation  and  maneuvers  by  the  Orbiter  will  verify  that  system 

The  only  candidate  for  checkout  is  the  IMU  and  main  propulsion  system.  The 
IMU  is  only  capable  of  partial  checkout  however,  so  quick  look  techniques 
will  be  used  Although  operational  status  is  mainly  verified  by  proper  main 
engine  operation,  some  engine  gimballmg  or  valve  sequencing  is  available  for 
limited  checkout 

6 6 POST-DEPLOY  CHECKOUT  OPERATIONS 

The  purpose  of  the  post-deploy  checkout  operations  is  clearly  stated  in  the 
following  definition 

POST-DEPLOY  CHECKOUT  - TUG  STATUS/CHECKOUT  REPORTING  TO  COMMIT  THE 
TUG  TO  MISSION 

661  Post-Deploy  Component  Activation 

Table  6 5 1-1  shows  the  acti vation/deactivation  sequence  recommended  forTug 
operations  As  is  shown  for  post-deploy,  the  Attitude  Propulsion  System  (APS) 
cannot  be  activated,  for  Orbiter  safety  reasons,  until  immediately  after 
deployment  The  mam  propulsion  will  be  activated  after  the  Orbiter  is  a 
safe  distance  from  the  Tug 
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Table  652-1  Tug  Flight  Operations  Functional  Allocation  (Pre-Deploy) 


ALLOCATION 

FUNCTION 

TUG 

ORB  ITER 

GROUND 

C&W/SAFETY  MONITORING/CONTROL 

X 

B/U 

TUG  STATUS  MONITORING 

B/U 

X 

VENTS,  PURGES 

X 

■fi/ua 

B/U 

IMU  ACTIVATION 

X 

B/U 

IMU  INITIALIZATION,  CHECKOUT 

X 

B/U 

NAVIGATION,  ATTITUDE  UPDATES 

X 

B/U 

DEPLOYMENT  ADAPTER  OPERATIONS 

X 

RMS  OPERATIONS 

X 

POWER  TRANSFER 

X 

COMMUNICATIONS  ACTIVATION 

X 

ORBITER/TUG  RF  VERIFICATION 

X 

PRIME  = X 

BACKUP  NO  1 = B/U, 
BACKUP  NO.  2 - B/U^ 


Table  6 5 3-1  Tug  Major  Component  Checkout/Momtormg  Summary 


§ § 

% 53 

§! 

o 


3 


OQ 


O) 

Oi 


DEPLOYMENT 

. RETRIEVAL 

COMPONENT/SUBSYSTEM 

PRE-DEPLOY 

POST-DEPLOY 

PRE-RETRIEVAL 

POST-RETRIEVAL 

DMS 

S50 

$,0 

S,0 

S,0 

IMU 

s5o,a,c 

S,0 

S,0 

S,D 

ELECTRICAL  POWER 

S,0 

S,0 

S,0 

S,D 

COMMUNICATIONS 

SsO,A 

S50 

S,0 

S,D 

APS 

S 

S ,0,A 

S,0,D 

S 

MAIN  PROPULSION 

S 

S»0,A,C 

Ss0,D 

GN&C  UPDATE  SENSORS 

S 

S,0,A 

S ,0,D 

RENDOCK  SENSORS 

S 

S,0,A 

S,0,D 

S> - STATUS  MONITORING 
0 - OPERATIONAL  MONITORING 
A - ACTIVATION  MONITORING 
C - CHECKOUT 

D - DEACTIVATION  MONITORING 


The  GN&C  update  sensor  will  be  activated  prior  to  the  first  mam  propulsion 
burn  to  receive  a navigation  update.  The  rendezvous  and  docking  sensors  will 
be  activated  prior  to  the  rendezvous  and  docking  phase  of  the  mission 

662  Post-Deploy  Flight  Operations  Functional  Allocation 

Table  6 6 2-1  shows  the  major  flight  operations  activities  to  be  performed 
for  the  Tug  post-deployment  and  the  allocation  of  functions,  either  prime  (X) 
or  backup  (B/U).  The  functions  include  the  on-orbit  operations  after  Tug 
deployment 

During  the  post-deploy  phase,  the  Orbiter  is  prime  for  safety  related  func- 
tions and  for  functions  related  directly  to  deployment  Therefore,  as  shown, 
most  activities  during  the  deployment  phase  are  controlled  by  the  Orbiter. 

The  Tug  is  prime  for  APS  final  activation  and  MPS  activation  and  sequencina 
which  would  not  affect  the  crew  safety,  while  the  ground  is  prime  only  for 
monitoring  functions  The  ground  is  also  backup  for  contingency  operations 


6 7 PRE-RETRIEVAL  CHECKOUT  OPERATIONS 

The  purpose  of  pre-retrieval  checkout  operations  is  clearly  stated  by  the 
following  definition 

PRE-RETRIEVAL  CHECKOUT-TUG  STATUS/CHECKOUT  REPORTING  TO  COMMIT  THE 
TUG  TO  RETRIEVAL 

671  Pre-Retrieval  Component  Deactivation 

Table  6 5 1-1  shows  the  deactivation  sequence  recommended  for  Tug  operations 
Deactivation  will  occur  soon  after  concluding  use  to  conserve  operating  life 
and  power  APS  is  deactivated  just  prior  to  retrieval  because  it  is  required 
to  maintain  a stable  attitude 

672  Pre-Retrieval  Flight  Operations  Functional  Allocation 

Table  6 7 2-1  shows  the  major  flight  operations  activities  to  be  performed 
for  the  Tug  retrieval  and  the  allocation  of  functions,  either  prime  (X)-or 
backup  (B/U)  The  functions  include  the  on  orbit  operations  pnor’to  the 
Tug  retrieval 

As  shown,  the  Tug  is  prime  for  certain  deactivation  and  sequencing  which 
would  not  affect  the  crew  safety,  while  the  ground  is  prime  only  for  monitoring 
functions  The  ground  is  also  backup  for  contingency  operations 

During  the  retrieval  phase,  the  Orbiter  is  prime  for  safety  related  functions 
and  for  functions  related  directly  to  retrieval  Therefore,  most  activities 
during  the  retrieval  phase  are  controlled  or  backed  up  by  the  Orbiter  For 
pre-retrieval  however,  the  Tug  is  prime  while  generally  post-retrievaT  the 
Orbiter  is  prime 
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Table  6 62-1  Tug  Flight  Operations  Functional  Allocation  (Post-Deploy) 


FUNCTION 

TUG 

ALLOCATION 

ORBITER 

GROUND 

APS  INITIAL  ACTIVATION 

X 

B/U 

C&W/ SAFETY  MONITOR/CONTROL 

X 

B/U 

TUG  STATUS 

B/U 

X 

APS  FINAL  ACTIVATION 

X 

B/u2 

' B/Uj 

MPS  ACTIVATION,  CHECKOUT 

V 

i 

j 

X 

B/U 

PRIME  - X 

BACKUP  NO  1 - B/U, 
BACKUP  NO  2=  B/U| 


6-18 


Table  6 7 2Z1  Tug  Flight  Operations  Functional  Allocation  (Retrieval) 


PRE-RETRIEVAL 

TUG 

ALLOCATION 

ORBITER 

TUG  STATUS  MONITORING 

B/U 

C&W/ SAFETY  MONITOR/CONTROL 

X 

MPS  DEACTIVATION/SAFING 

X 

b/u2 

GN&C  SENSOR  DEACTIVATION 

X 

PROPELLANT  DUMP 

X 

b/u2 

ACS  INITIAL  INHIBIT 

X 

b/u2 

POST-RETRIEVAL 

C&W/SAFETY  MONITOR/CONTROL 

X 

TUG  STATUS  MONITOR 

B/U 

ACS  FINAL  INHIBIT/DEACTIVATION 

X 

COMMUNICATIONS  DEACTIVATION 

X 

POWER  SWITCHING 

X 

FUEL  CELL  DEACTIVATION 

X 

B/U 

IMU  DEACTIVATION 

X 

B/U 

GROUND 

X 

B/U 

B/Ul 

B/U 

B/Ux 

B/Ua 


B/U 

X 


PRIME  = X 

BACKUP  NO  1 = B/U, 
BACKUP  NO  2 = B/U^ 


6 8 POST-RETRIEVAL  CHECKOUT  OPERATIONS 

The  purpose  of  post-retrieval  checkout  operations  is  clearly  stated  by  the 
following  definition 

POST-RETRIEVAL  CHECKOUT  - TUG  STATUS/CHECKOUT  REPORTING  TO  COMMIT  TO 
DEORBIT  WITH  A SAFE  TUG 

681  Post-Retrieval  Component  Deactivation 

Table  6 5 1-1  shows  the  deactivation  sequence  recommended  for  Tug  operations 
Deactivation  will  occur  soon  after  concluding  use  to  conserve  operating  life 
DMS  remains  on  for  status  keeping  telemetry  generation 

682  Post-Retrieval  Flight  Operations  Functional  Allocation 

This  is  covered  by  the  text  of  6 7 2 Pre-Retrieval  Flight  Operations  Func- 
tional Allocation  and  the  lower  portion  of  Table  6 7 2-1 

6 9 ORBITER  IMPACTS  SUMMARY 

An  assessment  of  the  Orbiter  impacts  based  on  the  results  of  the  Tug  deployment 
and  retrieval  operations  was  made  to  determine  if  potential  Orbiter  support 
problems  exists.  This  section  presents  a discussion  of  the  Orbiter  operational 
support  functions  for  the  Tug  which  would  impact  Orbiter  software  and  a 
computer/software  sizing  estimate  to  support  those  functions 

691  Operations  Support  Functional  Description 

The  Orbiter  functions  required  to  support  the  Tug  on-orbit  flight  operations 
are  summarized  in  Table  6 9 1-1  Since  the  Orbiter  is  required  to  monitor 
selected  Tug  safety  and  status  parameters,  the  Orbiter  must  process  the  Tug 
telemetry  data  stream  to  the  Orbiter  (16KPBS)  and  retrieve  the  data  parameters 
required  for  analysis  After  the  correct  C&W,  safety  and  status  parameters 
are  selected,  the  Orbiter  will  compare  those  parameters  with  the  expected 
results  or  limits  and  store  the  data  for  future  display  by  the  Orbiter  C&D 
as  required 

The  Orbiter  will  also  monitor  the  operational  status  of  all  Tug  mission  critical 
components  as  a basis  for  operational  impacts  Any  anomalies  detected  by  the 
Orbiter  will  be  evaluated  and,  if  necessary,  corrective  command  action  will 
be  taken  to  alleviate  the  anomaly 

The  Orbiter  is  also  required  to  initiate  or  support  selected  Tug  activation, 
deactivation  or  operational  support  sequences  while  the  Tug  is  attached  or  in 
close  proximity  to  the  Orbiter  These  functions  include'power  transfer  and 
deactivation.  Tug  communications  activation  and  verification  and  deactivation, 
APS  initial  activation  and  final  deactivation,  Tdg  navigation,  attitude  or 
target  updates,  and  initialization  of  the  Tug  IMU  after  it  is  activated  on- 
orbit  After  initialization,  the  Orbiter  will  perform  attitude  maneuvers  to 
assure  the  Tug  IMU  is  operating  properly  by  comparing  the  state  vectors 
State  vector  updates  will  be  provided  if  required  These  support  functions 
are  included  in  the  nominal  mission  timeline 
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Table  6 9 1-1  Orbiter  Software  Functions  to  Support  Tug 


„ i SAFETY/STATUS  MONITORING 

TUG  TELEMETRY  PROCESSING  (16  KBPS) 

C&W/SAFETY  PARAMETER  MONITORING/CONTROL 
SELECTED  TUG  SUBSYSTEM  STATUS  MONITOR/CONTROL 


• TLTg  INITIALIZATION  ACTIVATION  AND  DEACTIVATION  SUPPORT 

IMU  INITIALIZATION,  ORBITER  MANEUVERS  AND  STATE  VECTOR  COMPARISONS 

POWER  TRANSFER/DEACTIVATION 

NAVIGATION,  ATTITUDE  AND  TIMING  UPDATES 

COMMUNICATIONS  ACTIVATION,  VERIFICATION  AND  DEACTIVATION 

APS  INITIAL  ACTIVATION  AND  FINAL  DEACTIVATION 


• CONTINGENCY  SEQUENCING  SUPPORT 

ACTIVATION/DEACTIVATION  (APS,  MPS,  IMU,  FUEL  CELL) 
DEACTIVATION  (GN&C  SENSORS) 

PROPELLANT  DUMP,  VENTS  AND  PURGES 
ABORT  SEQUENCING 


« MISCELLANEOUS  ORBITER  SUPPORT 

DEPLOYMENT/RETRIEVAL  OPERATIONS 
REMOTE  MANIPULATOR  OPERATIONS 
COMMUNICATION  SWITCHING/RECORDING  MANAGEMENT 
TUG  ATTITUDE-COLLISION  AVOIDANCE  MONITORING 


For  the  activation  and  deactivation  sequencing,  commands  would  be  sent  and 
data  received  to  determine  if  satisfactory  results  were  obtained.  The  Tug 
state  vector  evaluation  would  be  more  complex  with  the  comparisons  evaluated, 
and  updates  initiated  if  required  ' “ ' 

i 

The  Orbiter  will  also  provide  limited  capability  to  support  contingency 
operations  associated  with  the  Tug,  such  as  abort  sequencing,,  subsystem 
activation  and  deactivation  sequencing,  vents  and  purges  These  functions 

would  only  be  required  for  contingency  operations  and  could  either  be 
hardwired  or  commanded  through  the  RF  link  Except  for  abort  sequencing, 
which  is  a prime  Orbiter  function,  most  of  the  contingency  activation/deac- 
tivation  sequencing  is  backup  to  both  the  Tug  and  ground 

The  Orbiter  also  provides  operations  support  for  the  Tug  when  the  Tug  vehicle 
or  subsystems  are  not  actively  involved  in  the  operations  Examples  of  these 
types  of  functions  include  RMS  remote  manipulator  operations,  communication 
switching  and  recording  of  Tug  telemetry  and  commands,  deployment  operations 
and  collision  avoidance  computations  These  items  may  not,be  charged  to  the 
Tug/Spacecraft,  but  are  defined  as  necessary  to  support  Tug  operations 

692  Computer/Software  Impacts 

The  basic  Orbiter/Tug  on-orbit  operations  philosophy  was  to  perform  as  many 
of  the  required  software  functions  in  the  Tug  as  possible,  which  would  mean 
that  the  Orbiter  would  only  initiate  sequences  which  would  be  performed  by 
the  Tug  This  is  especially  true  for  the  activation  and  deactivation  sequenc- 
ing This  section  reviews  the  Orbiter  software  functions  sized  to  support 
the  Tug  Functions  to  support  the  Spacecraft  were  not  sized. 

6921  Sizing  Summary 

A summary  of  the  Orbiter  software  storage  impacts  to  support  the  Tug  operations 
are  given  in  Table  6 9 2-1  The  functions  to  be  sized  were  discussed  in  the 
previous  section,  and  are  divided  into  two  groups,  Orbiter  interactive 
support  for  Tug  and  Orbiter  controlled  support  for  Tug.  The  interactive 
support  includes  the  Tug/Orbiter  interfaces  and  operations.  Tug  safety/status 
monitoring,  Tug  subsystem  initialization  activation,  deactivation  and  opera- 
tions support,  and  backup  or  contingency  sequencing  support.  The  Orbiter 
controlled  support  includes  overhead  to  the  Orbiter  operating  system  (OS) 
and  Tug  displays,  controls. in  the  MSS,  and  miscellaneous  support  provided  to 
the  Tug  such  as  remote  manipulator,  communications  and  deployment  adaptor 
operations  which  are  done  independent  of  Tug  involvement  Some  of  the  Orbiter 
controlled  support  items  may  not  be  charged  to  the  Tug 

The  sizing  assumes  that  a 75%  short  and  25%  long  mix  for  both  instructions 
and  data  is  used  to  obtain  the  total  Orbiter  storage  requirements  The 
Orbiter  is  baselined  with  a 32  bit  word  length  for  storage.  The  summary  in 
Table  6 9 2-1  indicates  that  approximately  16K  of  32  bit  words  is  required  in 
the  Orbiter  DMS,  assuming  that  both  interactive  support  and  Orbiter  controlled 
support  are  charged  to  the  Tug  But,  since  only  a portion  of  the  total  storage 
is  required  at  any  one  time,  only  about  2 5K  of  32  bit  words  is  required  'in 
main  storage  at  one  time  Therefore,  the  Tug  required  software  can  be  stored 
in  the  Orbiter  mass  storage  and  called  into  main  memory  when  required  for 
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Table  692-1  Orb/ter  Software  Sizing  to  Support  Tug 


INST 

DATA 

*T0TAL 
(32  BIT 
WORDS) 

MAX  MAIN 
MEMORY 
(32  BIT 
WORDS) 

• INTERACTIVE  SUPPORT  FOR  TUG 

K 

SAFETY/STATUS  MONITORING 

350 

9,055 

5,878 

1,031 

INITIALIZATION,  ACTIVATION 

* 

AND  DEACTIVATION 

2,450 

1,030 

2,175 

938 

CONTINGENCY  SEQUENCING 

SUPPORT 

3,800 

2,675 

4,047 

- 

SUBTOTALS 

6,600 

12,760 

12,100 

1,969 

• ORBITER  CONTROLLED  SUPPORT 

MSS  SUPPORT  SOFTWARE 

(OVERHEAD) 

500 

350 

531 

531 

MISCELLANEOUS  ORBITER  SUPPORT 

3,200 

2,450 

3,532 

- 



3,700 

2,800 

4,063 

531 

^ASSUME  75%  SHORT  AND  25%  LONG  INSTRUCTION  AND  DATA  MIX 


operations.  The  major  Orbiter  storage  impacts  are  for  Tug  display  formats  and 
data  (12  formats  assumed)  which  will'  be  displayed  in  "the  Orbiter  for  safety  and 
status  monitoring  The  functions  sized  have  extremely  low  execution  rates,  and 
when  coupled  with  low  instruction  numbers,  a minimal  speed  impact  to  Orbiter  is 
expected  The  Orbiter  support  requirements  appear  to  be  well  within  the  support 
capability  of  10K  main  memory  and  18  KOPS  provided  to  payloads  by  the  Orbiter, 
assuming  the  Tug  support  programs  can  be  stored  in  the  Orbiter  Mass  Storage  and 
called  into  mam  storage  when  required. 

6922  Interactive  Support  Details 

The  interactive  support  sizing  details  include  safety/status  monitoring, 
activations/operations  support,  contingency  sequencing  support,  and  are  shown 
in  Tables  6 9 2-2  through  -4 

The  safety/status  monitoring  support  (Table  6 9 2-2)  lists  the  items  sized. 

The  16  KPBS  telemetry  stream  from  the  Tug  is  processed  by  the  Orbiter  to 
selected  the  estimated  100  (of  about  200  total  Tug)  telemetry  parameters  which 
would  be  used  by  the  Orbiter  for  safety  and  status  monitoring  The  parameters 
requiring  limit,  status,  or  go/no-go  checks  are  processed  by  the  Orbiter  com- 
puter for  anomaly  reporting  The  Tug  data  will  be  grouped  into  display  formats 
and  associated  display  parameters  for  use  by  the  MSS  personnel.  Twelve 
displays  are  assumed  and  the  display  format  (or  display  background)  and  the 
mapping  tables,  which  select  the  parameters  to  be  displayed  on  the  format, 
were  included  in  the  sizing  As  shown,  the  display  images  (or  formats)  are 
the  main  storage  impacts,  with  a total  storage  requirement  of  4 5K  of  32  bit 
words 

The  initialization,  activation,  deactivation  and  operations  sequencing  by  the 
Orbiter  to  support  the  Tug  (Table  6 9 2-3)  are  the  power  transfer,  ACS  initial 
arming,  communications  activation  and  verification,  and  Tug  state  vector 
comparison  and  update  during  deployment,  and  APS  deactivation,  fuel  cell 
deactivation,  and  communications  deactivation  during  retrieval  The  commands 
are  in  tables  which  contain  the  command  address,  time  of  issuance,  sequence 
dependency,  verification  response  from  the  Tug  and  error  processing  indication, 
if  required  The  GN&C  update  capability  will  provide  an  evaluation  of  the  Tug 
state  vector  to  determine  the  need  for  an  update  and  to  provide  the  updates 
if  required  Only  about  2 2K  are  required  for  these  items. 

The  contingency  sequencing  support  (Table  6 9 2-4)  provides  backup  activation/ 
deactivation  or  sequencing  capability  to  support  the  Tug  The  items  sized 
include  a more  detailed  activation/deactivation  sequence  than  required  for 
normal  operations  and  would  be  used  only  if  Tug  (or  ground)  operation  were 
not  feasible  The  abort  sequencing  is  controlled  only  by  the  Orbiter,  but  was 
included  in  the  contingency  support  since  it  is  not  required  during  normal 
on-orbit  opearations  Approximately  4K  of  storage  is  required  for  the  contin- 
gency sequencing  support 

6923  Orbiter  Controlled  Support 

The  functions  sized  for  Orbiter  controlled  support  do  not  interface  with  the 
Tug,  but  provide  support  for  Tug  operations.  These  include  MSS  support 
software  and  miscellaneous  Orbiter  support  The  sizing  impacts  are  shown, 
respectively,  in  Tables  6 9 2-5  and  6 9 2-6 
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Table  6 9 2-2.  Safety  /Status  Monitoring  Sizing 


FUNCTION 

INSTRUCTIONS 

DATA 

TOTALS 

(32  BIT  WORDS) 

TELEMETRY  STREAM  PROCESSING 

250 

750 

625 

LIMIT  TESTING/STATUS 
CHECKING 

100 

25 

78 

DISPLAY  IMAGES  (12  IMAGES  0 
600  WORDS/DISPLAY) 

7,200 

4,500 

DISPLAY  MAPPING  TABLES  (12 
IMAGES  X [6  WORDS/ IMAGE 
ENTRY  X 15  ENTRIES]  ) 

1,080 

675 

TOTALS 

350 



9,055 

5,878 
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Table  6 92-3  Initialization,  Activation  and  Deactivation  Sizing 


FUNCTION (*) 

INSTRUCTIONS 

DATA 

TOTAI  S 

(32  BIT  WORDS) 

POWER  TRANSFER 

200 

70 

169 

APS  ARMING 

250 

80 

206 

APS  DEACTIVATION 

250 

80 

206 

FUEL  CELL  DEACTIVATION 

250 

100 

219 

UPDATE  GN&C  PARAMETERS 

1,000 

500 

937 

COMMUNICATION  ACTIVATION/ 
VERIFICATION 

250 

100 

219 

COMMUNICATION  DEACTIVATION 

250 

100 

219 

2,175 

{*)  ONLY  ONE  FUNCTION  IS  RESIDENT  IN  ORBITER  MEMORY  AT  ANY  TIME 
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Table  692-4  Contingency  Sequencing  Support 


FUNCTION (*) 

INSTRUCTIONS 

DATA 

TOTALS 

(32  BIT  WORDS) 

MISSION  SEQUENCE  START 

50 

25 

47 

TUG  IMU/DMS  INITIALIZATION/ 
ACTIVATION 

500 

500 

625 

FUEL  CELL  ACTIVATION 

- ro 
o 
o 

150 

219 

APS  ACTIVATE 

200 

150 

219 

APS  DEACTIVATION 

200 

150 

219 

MPS*  ACTIVATION 

200 

150 

219 

MPS  DEACTIVATION 

200 

150 

219 

GN&C  COMPONENT  ACTIVATION 

500 

250 

268 

PROPELLANT  DUMP 

500 

250 

468 

VENTS/PURGES 

500 

250 

649 

ABORT  COMMANDING 

750 

650 

875 

' TOTALS 

3,800 

2,675 

4,047 

<*)  ONLY  ONE  FUNCTION  OCCUPIES  ORBITER  COMPUTER  MEMORY  AT  ANY  TIME. 
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Table  6 9 2-5  MSS  Support  Software  ( Overhead)  Sizing 


FUNCTION 

INSTRUCTIONS 

DATA 

TOTALS 

(32  BIT  WORDS) 

'FUNCTION/PHASE  INITIALIZATION 

500 

100 

374 

TABLES  FOR  OS  INPUT/OUTPUT 

UTILIZATION 

250 

156 

TOTALS 

500 



350 

531 

8Z9 


Table  69,2-6  Miscellaneous  Orbiter  Support  Sizing 


FUNCTION 

INSTRUCTIONS 

DATA 

TOTALS 

(32  BIT  WORDS) 

RMS  OPERATIONS 

1,000 

500 

938 

TUG  ATTITUDE/COLLISION 
AVOIDANCE 

250 

150 

250 

DEPLOYMENT  SEQUENCING 

750 

750 

938 

UMBILICAL  MECHANISMS 

500 

500 

625 

CAPTURE  LATCHES  CONTROL 

500 

500 

625 

COMMUNICATIONS  MGMT 

200 

50 

156 

TOTALS 

3,200 

2,450 

3,532 

The  MSS  support  software  (Table  6 9 2-5)  includes  function/phase  initiali- 
zation and  tables  for  the  Orbiter  computer  operating  system  (OS)  input/ 
output  utilization  The  function/phase  initialization  sizing  includes  the 
selection  of  displays,  responses  to  keyboard  entries,  priority  assignments 
and  loading  data  from  mass  storage  The  I/O  table  includes  items  the  Orbiter 
OS  must  support,  such  as  valid  command  tables  and  display  linkage  tables 
The  Orbiter  storage  impact  is  531  words 

The  miscellaneous  support  (Table  6 9.2-6)  includes  remote  manipulator  opera- 
tions, deployment  sequencing,  Orbiter  communications  management  to  support 
Tug  telemetry/commands  and  collision  avoidance  computations  The  storage 
impact  for  these  items  is  about  3 5K 
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SPACECRAFT  DEPLOYMENT  "7 
RENDEZVOUS  AND  DOCKING  OPERATIONS  ANALYSIS  l 


The  primary  responsibility  of  the  Space  Tug  is  to  deliver  a Spacecraft  to 
a desired  location  or  obital  condition,  and  in  some  instances,  to  rendez- 
vous and  dockwth  another  Spacecraft  and  retrieve  or  service  Although 
the  Tug  will  be  designed  with  the  capability  to  provide  support  to  attached 
Spacecraft,  the  Spacecraft  community  desires  that  minimum  operational 
interfaces  exist  between  the  Spacecraft  and  Tug,  except  for  servicing 
missions  by  the  Tug  Some  operational  interfaces  are  planned  between  the 
Spacecraft  and  Tug  This  section  will  discuss  the  deployment  of  Spacecraft  as 
well  as  the  rendezvous  and  docking  operations  associated  with  retrieval  of 
Spacecraft 

7 1 SPACECRAFT  DEPLOYMENT 

This  section  discusses  predeployment  and  postdeployment  operations 

t 

7 1 1 Spacecraft  Predeploy  Operations 

This  section  discusses  the  Spacecraft  predeploy  operations  which  include  the 
activities  from  the  final  Tug  mainstage,  or  trim  burn,  maneuver  until  physical 
separation  of  the  Spacecraft  from  the  Tug 

7111  Tug  Support 

The  major  Tug  functions  in  support  of  the  Spacecraft  predeploy  operations  are 
to  provide  an  attitude  control  base  for  the  Spacecraft  while  it  is  being 
activated  and  checked  out,  to  provide  activation  and  separation  sequencing 
support  and,  in  some  cases,  to  provide  the  communication  link  interface  with 
the  ground  The  Tug  may  also  provide  the  capability  of  monitoring  Spacecraft 
status  and  providing  aid  to  correct  the  malfunctions 

During  the  phases  when  the  Spacecraft  is  being  ferried  from  low  earth  orbit 
to  its  final  destination,  the  Spacecraft  may  provide  its  own  RF  communications 
links  with  the  ground  For  some  payloads,  however,  the  Spacecraft  RF  communi- 
cation links  will  be  covered  or  partially  covered  by  shrouds,  payload  adapters, 
other  Spacecraft,  appendages,  etc  , and,  for  those  cases,  Spacecraft  telemetry 
will  be  integrated  with  the  Tug  RF  communications  for  relay  to  the  ground 
The  command  uplink  for  the  Spacecraft  will  also  be  relayed  through  the  Tug 
During  the  Spacecraft  predeploy  operations,  the  ground  interface  would  be 
through  the  Tug  until  the  Spacecraft  antennas  were  uncovered  on  until  separa- 
tion of  the  Spacecraft  In  some  cases,  the  ground  will  use  the  Tug  command 
interface  with  the  Spacecraft  through  the  forward  DIU  to  execute  selected 
functions  initiated  by  the  Spacecraft  Operations  Center  (SOC) 

The  Tug  provides  an  attitude  control  base  for  the  Spacecraft  during  the  pre- 
deploy operations  The  Tug  will  maintain  attitude  control  for  both  the  Tug 
and  Spacecraft  until  they  are  separated  This  allows  the  Spacecraft  to  be 
activated,  its  appendages  extended,  and  the  attitude  control  and  RF  ground 
interfaces  to  be  verified  prior  to  separation  If  Spacecraft  anomalies  occur, 
the  Tug  can  maintain  the  attitude  base  for  a limited  time  until  work-around 
corrective  action  can  be  taken  by  the  ground 
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The  Tug  is  expected  to  provide  direct  support  to  Spacecraft,  and  these 
services  will  be  optimized  or  minimized  to  the  extent  possible  The  two  mam 
Tug  support  functions  are  Spacecraft  activation  sequencing  and  Spacecraft 
orientation  and  spin-up,  if  required  The  activation  sequencing  may  be 
initiated  or  performed  by  the  ground,  however,  the  Tug  will  provide  sequencing 
interface  capability,  through  the  forward  DIU  from  the  Tug  computer,  for  such 
as  shroud  deployment,  antenna  deployment,  solar  array  deployment,  and  power 
activation.  If  required,  the!  Tug  will  provide  the  operation  base‘for  the 
orientation  and  spm-up  of  a Spacecraft  prior  to  separation.  The  Tug  may  also 
monitor  critical  Spacecraft  parameters  and  react  to  jinomaly  situations, 
although  this  capability  is  not  particularly  desired  by  the  Spacecraft 
community  Since  the  Tug  is  a reusable  vehicle,  the  Tug  would  be  capable  of 
jettisoning  an  inoperative  or  potentially  hazardous  Spacecraft  if  it  had  the 
potential  to  destroy  the  Tug  Therefore,  the  monitoring  of  Spacecraft 
potentially  hazardous  conditions  by  the  Tug  is  desirable 

Prior  to  final  release  of  the  Spacecraft  by  the  Tug,  a retrieval  assurance 
checkout  would  be  made  to  assure  an  immediate  or  later  retrieval  of  th'e 
Spacecraft  is  possible  A typical  checkout  list  is  as  follows,  with  items 
necessary  for  retrieval  indicated  by  an  astenk., 

• Verify  deployment  of  appendages 

t Verify  payload  orientation  and  stability 

• Check  payload  uplink  and  downlink  transmission  to  ground 

• Check  telemetry  transmission  by  payload 

• Verify  readiness  for  separation 

• Check  payload  on  internal  power 

• Check  retrieval  kit  items 

*Retrieval  battery  readiness  (nonactivated) 

*Laser  operation  (Tug  equipment) 

*Transponder  operation 

*#  Check  Tug  TV  for  docking  observation  capability 
These  checks  would  be  made  with  a combination  of  both  ground  and  Tug  support. 
7112  Ground  Support 

Both  the  Spacecraft  Operations  Center  (SOC)  and  the  Tug  Operations  Center  (TOC) 
will  actively  participate  m monitoring  and  controlling  vehicle  operations 
during  the  predeploy  operations 

The  TOC  will  be  primarily  responsible  for  monitoring  the  Tug  status  and  opera- 
tions to  assure  no  operational  or  anomaly  impacts  which  could  endanger  the 
Spacecraft  The  emphasis  will  be  on  critical  subsystem  status  and  hazardous 
situation,  such  as  tank  over  pressurization  There  will  be  extensive  interface 
between  the  SOC  and  the  TQC  during  this  phase  for  status  information,  for 
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attitude  and  operations  potential  conflicts,  and  to  assure  the  correct  pro- 
cedures are  executed  in  the  proper  sequence 

The  SOC  will  have  the  primary  responsibility  for  Spacecraft  activation  and 
operational  verification.  It  will  use  Spacecraft  telemetry  and  selected 
event  input  from  the  Tug  via  the  TOC  to  determine  if  the  Spacecraft  is  ready 
for  separation  and  if  all  Spacecraft  functions  are  operational  In  the  event 
of  a malfunction,  the  SOC  will  actively  command  and  control  the  Spacecraft  to 
eliminate  the  problem  Any  interaction  requests  for  the  Tug  will  be  relayed 
through  the  TOC  with  appropriate  feedback  to  the  SOC 

7 1 2 Spacecraft  Post- Deploy  Operations 

This  section  discussed  the  Spacecraft  deployment  operation  following  separation 
of  the  Spacecraft  from  the  Tug  until  the  Tug  is  a safe  distance  from  the 
Spacecraft 

7121  Tug  Support 

After  the  Spacecraft  separates  from  the  Tug,  the  Tug  will  maneuver  a short 
distance  from  the  Spacecraft  to  avoid  recontact  and  potential  Spacecraft  con- 
tamination and  will  provide  for  TV  inspection^  the  Spacecraft  and  also  for 
reattachment  capability  if  required  The  Tug  will  have  no  RF  link  interface 
-capability  with  the  Spacecraft,  so  all  interface  will  be  controlled  by  the 
TOC  and/or  the  SOC  The  primary  emphasis  of  the  inspection  will  be  on 
assuring  that  no  damage  has  been  done  to  the  Spacecraft  and  that  all  appendages 
are  properly  deployed 

After  the  inspection,  and  if  reattachment  is  not  required,  the  Tug  will 
maneuver  for  its  deorbit,  subsequent  Spacecraft  placement,  or  rendezvous  orbit 
and  proceed  with  its  mission 

7.1  2 2 Ground  Support 

After  separation,  the  SOC  has  the  prime  responsibility  for  the  Spacecraft, 
while  the  Tug  has  the  responsibility  to  assure  evasive  maneuvers  have  been 
performed  correctly  and  to  command  and  monitor  Tug  maneuvers  for  visual 
inspection  of  the  Spacecraft  Unless  the  SOC  provides  requirements  for 
maneuvers  to  inspect  particular  functions  of  the  Spacecraft,  a preprogrammed 
sequence  of  maneuvers  will  be  performed  by  the  Tug  to  allow  visual  inspection 
of  the  Spacecraft  If  reattachment  is  required,  the  request  will  be  made  by 
the  SOC  to  the  TOC,  and  the  TOC  will  initiate  the  required  command  sequence 
to  accomplish  docking  Another  primary  interaction  between  the  ground  centers 
is  required  to  avoid  recontact  or  contamination  of  the  Spacecraft  and  to 
identify  any  Tug  or  Spacecraft  problems  which  could  jeopardize  or  potentially 
impact  the  respective  missions  The  TOC  will  react  to  any  potential  Space- 
craft hazard  to  the  Tug  to  assure  Tug  safety  When  the  Tug  is  a safe  distance 
from  the  Spacecraft,  ground  center  interface  is  no  longer  required 
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The  SOC  will  monitor  the  Spacecraft  status  and  perform  any  required  activation, 
checkout  operational  monitoring,  and  commanding.  The  SOC  will  also  react  to 
any  potential  Tug  impacts  on  the  Spacecraft  should  they  occur 

7 2 RENDEZVOUS  AND  DOCKING  OPERATIONS 

This  special  emphasis  task  was  intended  to  describe  a general  rendezvous  and 
docking  operational  flow  and  to  employ  that  flow  description  in  developing 
implemental  relations  for  evaluating  subsystem  constraints  and  budgets.  The 
method  involved  the  review  and  assessment  of  proceding  study  results  Shuttle 
Sortie  Payload  Descriptions,  Automated  Payloads,  Level  A and  Level  B volumes, 
and  a logical  assessment  of  the  operational  sequences  required.  Following  the 
description  of  a general  functional  requirement,  the  flow  was  segregated  into 
operational  modules  and  submodules  so  that  each  contained  complementary  and 
distinct  functions 

These  functional  modules  were  defined  so  that  characteristic  parameters  could 
be  identified  The  intermodular  relations  of  the  parameters  were  described  in 
cases  where  meaningful  relations  could  be  derived  in  a timely  manner  The  goal 
of  parameterization  was  the  identification  of  these  relations  in  the  operational 
flow  so  that  subsystem  constraints  and  budgets  could  be  quantified  and  priori- 
tized for  mission  planning 

This  report  section  describes  the  rendezvous  and  docking  modules,  submodules 
and  functions  as  defined  during  the  study  A set  of  parameters  is  identified 
and  the  relations  between  some  of  the  parameters  are  presented  Emphasis  was 
placed  on  those  parameters  meaningful  to  rendezvous.  Other  meamnful  para- 
metric relations,  particularly  those  involving  translational  control  in  the 
docking  module  were  not  analyzed  because  of  lack  of  a six-degree-of-freedom 
Tug  simulation  including  a propellant  slosh  model. 

Before  delving  into  parameters  and  the  rationale  for  selection,  one  should 
understand  the  operational  flow  and  some  of  the  reasons  for  its  nature.  The 
rendezvous  and  docking  modules  are  described  with  the  respective  submodules  of 
each  in  the  following  paragraphs  Only  the  nominal  flow  is  addressed  in  these 
paragraphs  Some  ideas  regarding  autonomy  levels  and  alternate  paths  for 
abnormal  operation  are  presented  in  Section  723 

721  Rendezvous  Operations 

The  rendezvous  module  contains  submodules  named  Rendezvous  Acquisition,  Terminal 
Phase  Initiation  (TPI),  and  Terminal  Phase  Transfer  (TPT)  Rendezvous  Acquisi- 
tion is  primarily  the  detection  of  the  target  Spacecraft  and  initiation  of 
rendezvous  procedures  Terminal  Phase  Initiation  is  the  establishing  of  the 
desired  rendezvous  trajectory  This  trajectory,  together  with  trajectory  trim 
burns  and  braking  burns,  is  the  Terminal  Phase  Transfer  submodule 

This  rendezvous  sequence  was  based  upon  the  presumption  that  rendezvous  will 
begin  with  Tug  on  a stable  orbit  coelliptic  to  that  of  the  Target  and  a 
constant  differential  height  above  or  below  the  Target  The  submodule  defini- 
tions are  intended  to  be  sufficiently  broad,  however,  to  be  meaningful  m the 
case  when  Tug  is  being  flown  on  a quite  different  trajectory,  such  as  a direct 
ascent. 
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Having  one  rendezvous  method  rather  than  several  will  enhance  vehicle  and 
ground  software  reliability  and  configuration  control  Flight  control 
personnel  will  be  able  to  establish  and  learn  one  set  of  cues  for  use  in 
monitoring  the  flow 

7211  Rendezvous  Acquisition 

This  submodule  comprises  the  pointing  of  the  rendezvous  tracker  during  search, 
the  initial  acquisition  and  tracking  of  the  target  Spacecraft,  or  Target,  and 
the  adjustment  or  updating  of  the  Tug  state  vector  (Figure  7 2 1-1) 


PREDICTED 


Figure  721-1  Rendezvous  Acquisition 

Rendezvous  Acquisition  begins  with  the  Tug  on  a nominally  constant-differenti al- 
height  (CDH)  orbit  coplanar  and  coelliptic  to  the  Target  orbit  The  altitude 
difference  ( AH)  and  central  angle  differences  (a$)  between  Tug  and  Target 
result  from  the  targetting  of  prior  burns  and  from  the  positional  dispersions 
of  the  two  crafts,  targetting  will  be  selected  to  prevent  the  crafts  endangering 
one  another  and  to  place  the  Tug  in  a favorable  geometry  for  rendezvous 
initiation  The  latter  is  defined  as  being  either  below  and  behind  or  above 
and  ahead  of  the  Target  so  that  orbital  motion  will  tend  to  aid  rendezvous 
rather  than  hinder  it 

The  rendezvous  tracker  search  pattern  will  be  based  upon  the  best  estimate  of 
Target  state  provided  by  the  Spacecraft  Operational  Center 
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The  post-acquisition  tracker  data  will  be  employed  along  with  Tug  state  data 
to  yield  an  updated  Tug  state  vector  This  state  vector  will  be  compared 
with  the  present  value  for  reasonableness  and,  if  so  found,  the  Tug  state 
expression  will  be  updated  to  reflect  the  tracker  data  Should  acquisition  and 
initial  tracking  require  tracker  operation  at  ranges  near  the  tracker  specified 
maximum  capability,  so  that  error  can  be  introduced,  this  possibility  will  be 
flagged  for  use  in  tracking  reasonableness  tests  following  TPI 

The  functional  sequence  defined  for  Rendezvous  Acquisition,  as  well  as  for 
all  the  other  operational  submodules,  is  independent  of  the  implementation 
scheme  For  example,  the  rendezvous  tracker  can  be  the  same  device  as  the 
docking  tracker  but  the  function  during  rendezvous  is  different  than  that 
during  docking  In  rendezvous,  the  target  is  treated  as  a point  located  at 
some  range  and  angle  from  the  Tug.  In  docking,  knowledge  of  Target  relative 
attitude  is  also  required 

Another  example  of  differences  in  function  implementation  is  in  the  initial 
condition  for  Rendezvous  Acquisition  The  Tug  need  not  be  on  a CDH  orbit  upon 
initialization  of  Acquisition,  the  only  requirement  is  that  it  be  in  approx- 
imately the  same  position  previously  described,  i e , below  and  behind  or  above 
and  ahead  The  basic  difference  in  the  implementation  of  the  operational  flow 
would  occur  in  the  TPI  module  in  that  the  main  engine  burn  and  Tug  attitude 
would  compensate  for  the  velocity  differences  as  well  as  initiating  the  Lambert 
closure  Relatively  high  closing  velocities  at  Acquisition  may  require  long- 
range  tracking  so  that  the  burn  can  be  accomplished  without  endangering  the 
Tug  or  Target 

7212  Terminal  Phase  Initiation 

This  module  contains  the  targetting  calculations  and  the  main-engine  burn  which 
establishes  the  transfer  trajectory  The  targetting  will  generally  comprise 
the  definition  of  a Lambert  transfer 

The  central  angle  between  the  Tug  and  the  Target  at  the  time  of  entry  into  the 
TPI  submodule  will  define  the  type  of  Lambert  transfer  optimal,  sub-optimal 
or  inadvisable,  which  will  be  discussed  as  an  abnormal  case  Optimal  Lambert 
transfers  have  predictable  best  central  angles  for  TPI  as  illustrated  in  sub- 
sequent parametric  relations.  If  the  measured  central  angle  is  greater  than 
any  in  the  range  of  optimal  central  angles  for  the  measured  differential  height 
(AH),  then  the  TPI  initiation  time  and  the  transfer  arc  length  are  scheduled 
for  optimality  and  constrained  by  variables  and  parametric  relations  as 
discussed  in  Section  7.2  4 

Otherwise,  the  targetting  calculations  will  attempt  to  identify  non-optimal 
transfers  attainable  from  the  measured  Tug  state  with  a TPF  impulse  requirement 
within  the  budget  constraint  If  a non-optimal  transfer  is  possible,  the  TPI 
module  will  be  executed  without  delay 

The  problem  of  defining  non-optimal  transfers  is  understandably  related  to 
initial  conditions  and  is  not  bounded  as  well  as  that  for  optimal  transfer 
solutions 

Non-optimal  transfers  are  those  which  require  more  than  the  minimum  amount 
of  impulse  for  the  given  differential  height  and  transfer  angle.  An 
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optimal  transfer  must  be  initiated  at  a certain  central  angle  relative  to  the 
target,  but  a non-optimal  transfer  is  not  so  constrained  and,  thus,  may  be 
initiated  at  relative  central  angles  smaller  than  that  for  the  optimal  case 
Impulse  requirements  may  not  increase  at  a significantly  hiqh  rate  as  the  initial 
central  angle  deviates  from  the  optimal  value,  but  the  parametric  relation  was 
not  analyzed  because  of  a lack  of  time  Non-optimal  transfers  may  require 
significantly  shorter  tracker  acquisition  ranges  than  those  for  the  optimal 
without  significantly  increasing  impulse  requirements  Definition  and  analysis 
of  the  parametric  relation  between  initial  central  angle  and  the  impulse 
requirements  at  TPI  and  TPF  should  proceed  as  soon  as  possible. 

As  the  initial  range  between  the  vehicles  is  lessened,  the  problem  of  trans- 
ferring along  an  orbit  degenerates  to  a problem  of  closing  along  the  line-of- 
sight  between  the  vehicles  because  the  conic  parameter  differences  become 
insignificant  The  measure  of  insignificance  and  a best  boundary  range, 
defining  whether  come  rendezvous  is  required,  were  not  identified  Several 
simulation  cases  indicated  that  ranges  of  at  least  five  nautical  miles  can  be 
negotiated  directly  by  phase-plane  translational  control 

The  mam-engine  burn  executed  as  part  of  TPI  is  a standard  trim  burn  module 
which  is  described  in  Section  3 of  this  volume 

7213  Terminal  Phase  Transfer 

Tracking  resumes  as  soon  as  possible  following  TPI  to  identify,  as  Tug  nears 
the  Target,  trajectory  errors  resulting  from  initial  tracking  uncertainties  and 
TPI  burn  dispersions  Any  significant  errors  will  be  corrected  at  range-defined 
gates  early  m the  transfer  (Figure  7 2 1-2) 
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Figure  721-2  Terminal  Phase  Transfer 


Incorrect  Target-relative  sidespeed  will  be  manifested  as  line-of-sight  (LOS) 
angular  motion  Because  of  the  low  LOS  angular  rates  early  in  the  transfer, 
finite  periods  of  time  preceding  each  gate  will  be  required  for  measuring  the 
rate  relative  to  the  Tug  inertial  reference 
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Tug  braking  as  the  Transfer  is  completed  will  be  implemented  with  at  least 
two  small  burns  rather  than  one  as  with  TPI  This  will  minimize  the  likeli- 
hood of  Target  perturbation  or  contamination  by  Tug  APS  exhaust  The  impulse 
required  at  the  initial  braking  gate  will  be  determined  or  updated  following 
each  trajectory  trim.  The  range  of  this  gate  will  not  vary.  The  second  braking 
gate  range  and  impulse  will  be  functions  of  the  closing  velocity  One  scheme 
would  allow  the  first  braking  burn  to  compensate  for  60-90  percent  of  the  TPF 
impulse  requirement,  the  second  gate  to  brake  an  equivalent  amount,  and  allow 
the  range,  range-rate  phase  plane  initialized  following  the  second  braking 
to  distribute  the  remaining  10-40  percent  of  the  impulse.  The  range  of  the 
second  gate  would  be  calculated  as  a function  of  closing  velocity  so  that 
entry  into  phase-plant  control  would  occur  in  the  dead-band,  i.e.,  no  firings 
will  be  required  immediately  at  the  transition. 

The  impulse  for  the  final  braking  would  be  distributed  according  to  the  trans- 
lational control  law  so  that  higher  closing  velocities  cause  braking  to 
commence  further  out  from  the  target  rather  than  increasing  the  thrusting  at 
a given  range 

This  scheme  and  classical  ones  should  be  analyzed  for  economic  feasibility 
with  a Tug  simulation  with  six  degrees  of  freedom  and  a propellant  slosh  model. 

The  aim  of  the  nominal  flow  is  to  transition  to  the  docking  module  and  phase- 
plane  translational  control  without  reverting  to  stationkeeping  Stationkeep- 
ing may  occur  as  part  of  the  Docking  Inspection  and  Alignment  submodule,  to  be 
discussed  later,  but  this  will  be  at  a minimum  non-docking  approach  range 

7 2 2 Docking  Operations 

This  module  includes  Inspection  and  Alignment,  Closure,  and  Terminal  Docking. 

It  is  principally  distinguished  from  Rendezvous  operations  by  the  Tug  maneuver- 
ing in  response  to  the  relative  attitude  of  the  Target  A presumption  for  this 
flow  description  is  that  the  Target  attitude  will  be  stable  but  will  not  change 
to  aid  Tug  alignment  Additionally,  some  identifiable  and  standard  docking 
targets  such  as  corner-cube  reflectors  will  be  installed  on  the  target  for 
aiding  the  docking  tracker 

7221  Docking  Inspection  and  Alignment 

This  submodule  consists  of  closing  to  the  minimum  safe-approach  range,  the 
radius  of  the  safety  sphere,  and  maneuvering  about  the  target  to  support 
inspection  via  the  television  camera  and  the  docking-aid  search  by  the  tracker 
(Figure  7 2 2-1) 
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Figure  7 23-1  Docking  Inspection  and  Alignment 


The  radius  of  the  safety  sphere  will  be  a function  of  the  target  Spacecraft 
The  sphere  will  be  sufficiently  large  to  be  standard  for  all  Spacecraft  to 
be  inspected  by  Tug  This  would  be  consonant  with  operational  standardiza- 
tion Additional  constraints  on  the  inspection  orbit  radius  are  the  TV 
camera  field-of-view,  the  docking  tracker  field-of-view  and  the  docking-aid 
visibility  cone  The  distance  from  the  Tug  to  the  target  will  be  sufficient 
for  both  the  TV  and  docking  tracker  fields -of- view  to  contain  the  entire 
Spacecraft,  thus  requiring  no  maneuvering  of  the  Tug  attitude  other  than  that 
required  to  maintain  the  Tug  pointed  directly  toward  the  center  of  the  Spacecraft 

Inspection  will  be  flown  as  a combination  of  a maximum  of  four  orbits  about  the 
target  Once  inspection  is  completed,  as  determined  by  the  SQC  and  signaled 
via  a discrete  command  from  the  TOC,  the  Tug  will  proceed  directly  to  the 
docking  visibility  cone,  if  it  has  been  previously  intersected  Otherwise  the 
isometric  search  will  continue  for  the  maximum  of  four  circumnavigations 
about  the  target  Failure  to  acquire  will  be  an  anolmaly  If  the  docking-aid 
visibility  cone  subtends  a solid  angle  greater  than  ninety  degrees, 
two  circumnavigation  orbits  would  be  sufficient  for  acquisition  and  alignment 
The  completion  of  alignment  will  occur  when  the  docking  aids  are  in  sight  and 
being  tracked  Closure  can  then  commence  immediately,  assuming, 
of  course,  that  inspection  has  been  signaled  complete 
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7 2 2 2 Docking  Closure 

A closing-velocity  component  is  established  while  lateral  displacement  error 
is  being  nulled  (Figure  7 2.2-2) 
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Figure  72 2-2  Docking  Closure 


Lateral  displacement  and  attitude  angle  error  by  Tug  is  not  significant 
as  long  as  the  docking  tracker  is  locked  on,  but  when  the  Tug  is  sufficiently 
near  the  Target  for  the  imminent  onset  of  docking  tracker  attitude  blindness, 
the  lateral  and  angular  errors  must  be  within  the  allowable  docking  latch 
tolerance  The  range  of  this  blindness  gate  is  called  the  Commit  Range 

Various  closure  control  law  possibilities  can  be  postulated.  One  obvious  one 
would  establish  a closing  velocity  when  the  docking-aid  track  is  established 
and  null  the  lateral  error  during  the  closure  A simpler  law  would  null  the 
Tug  lateral  displacement  error  and  then  close  directly  down  the  docking  axis 
The  assessment  of  the  various  control  laws  requires  a dynamic  simulator  with 
slosh  model  and  allowing  interaction  to  simulate  ground  controller  functions 
and  to  aid  real-time  analysis 


7-10 


7 2 2 3 Terminal  Docking 

The  satisfaction  of  Commit  Range  tolerances  allows  penetration  of  the  gate 
with  an  inertial ly  fixed  attitude  parallel  to  the  docking  axis,  with  lateral 
errors  always  within  the  latch-permissible  ranges  and  with  the  optimum  contact 
velocity  (Figure  7.2  2 3) 
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Figure  7 2.2-3  Terminal  Dockmg 

Range  can  be  continuously  monitored  by  the  docking  tracker,  technology  per- 
mitting, through  the  use  of  a single  target  or  reflector  as  long  as  one  is  in 
view  Significant  interactions  exist  in  Terminal  Docking  attitude  blink 
ranges,  totally  blind  ranges,  RCS  lateral  deadband,  slosh,  and  contact  dynamics 
These  parameters  and  their  relations  will  be  defined  and  analyzed  with  a Tug 
dynamic  simulator  including  a detailed  slosh  model 

723  Non-Nominal  Paths 

A failure  to  acquire  the  Target  during  Rendezvous  Acquisition  will  prevent 
the  execution  of  an  optimal  TP I Burn  i he  TOC  would  have  the  option  of 
commanding  the  Tug  to  bypass  Acquisition  and  execute  TPT  with  the  presumption 
that  the  tracker  will  acquire  during  the  Transfer  High-quality  Tug  naviga- 
tion and  a low-range  tracker  could  yield  such  a situation  The  basic  flow 
would  proceed  as  defined  but  Tug  autonomy  and  efficiency  may  be  changed 

An  inadvisable  transfer,  as  referred  to  m Section  7 2 1 2,  is  one  requiring 
a prohibitive  impulse  expenditure  This  could  occur  if  the  Tug  were  below  and 
ahead  of  the  Spacecraft  or  above  and  behind  the  Spacecraft  The  immediate 
reaction  to  such  a transfer  will  be  the  definition  via  real-time  mission 
planning  of  one  or  more  transfer  or  phasing  orbits  to  place  the  Tug  in  a favor- 
able position  for  Rendezvous  initiation.  Being  forced  into  unpredicted  phasings 
and  transfers  will  require  a complete  redefinition  and  prioritization  of  the 
balance  of  the  Tug  mission 
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Failure  of  the  television  system  onboard  would  not  of  itself  prevent  any  of  the 
critical  functions  from  executing  but  a valuable  supervisory  tool  would  be 
removed  Extensive  ground  processing  of  rendezvous  tracker,  docking  tracker, 
inertial  system  attitude,  Tug  navigation  state  and  Target  inertial  attitude 
may  result  m artificial  intelligence  approximating  a TV  picture  but  the 
advisability  of  defining  the  system  required  to  support  such  a capability  is 
not  clear 

Failure  of  the  docking  sensor  to  acquire  when  the  television  indciates  visi- 
bility of  the  dockmg-aid  targets  is  an  anomaly  because  the  baseline  system 
for  this  study  depends  upon  a scanning  laser  radar  for  relative  attitude,  and 
range  information  However,  television  may  be  a suitable  docking  sensor, 
given  adequate  support  displays,  and  software  and  controls. 

Failure  to  latch  at  Terminal  Docking  contact  will  cause  the  Tug  to  automatically 
revert  to  Commit  Range  for  attitude  and  state  reassessment.  An  uplinked 
release  command  by  TOC  is  required  before  Terminal  Docking  is  attempted  again 

724  Operational  Parameter  Definitions  and  Relations 

Once  the  submodules  were  functionally  segregated,  the  variables  active  in  each 
function  were  identified.  Because  this  was  an  initial  effort,  compiling  an 
initial  set  of  representative  and  significant -parameters  was  emphasized  rather 
than  gleaning  for  an  exhaustive  set  (Table  7 2 4-1) 

The  worth  of  the  compilation  lay  in  defining  the  interaction  of  the  parameters. 
Of  particular  interest  were  the  module  interfaces  at  the  entry  to  Rendezvous 
Acquisition  and  at  the  exit  from  Terminal  Phase  Transfer.  Three  types  of 
relationships  are  shown  Figures  7 2 4-1  through  7 2 4-24  illustrate  the 
relation  between  acquisition  range  and  the  time  remaining  until  TPI  for  various 
differential  height  and  targetted  transfer  angles  These  curves  can  be 
employed  for  evaluating  the  impact  of  a minimum  time  requirement  between 
acquisition  and  the  TPI  boost 

The  relations  between  example  TPI  impulse  budgets  and  targetted  optimal  transfer 
arcs  for  several  differential  heights  at  each  of  the  target  altitudes  are 
illustrated  in  Figures  7 2 4-25  through  7 2 4-27  The  impulse  budget  con- 
straint causes  favoring  of  minimal  differential  heights  or  long  transfer  arcs 
The  example  budgets  are  included  as  aids  for  chart  interpretation 

Each  optimal  Lambert  transfer  may  be  characterized  at  TPI  by  the  slant  range 
between  the  two  vehicles  These  slant  ranges  are  the  minimum  acquisition 
ranges  (Figures  7 2 4-28  through  7 2 4-30).  These  data,  already  shown  in  the 
acquisition  range/time-to-TPI  relations  (Figures  7 2.4-1  through  7 2 4-24) 
are  illustrated  here  with  emphasis  on  the  relation  between  impulse-possible 
transfer  arcs  and  required  minimum  acquisition  range  When  the  two  charts  for 
a given  target  altitude  (e  g.,  7.2.4-25  and  7 2 4-28)  are  viewed  together,  the 
effect  of  the  impulse  budget  on  the  minimum  required  acquisition  range  is 
visible  (Table  7 2 4-2)  For  the  illustrated  differential  heights,  transfer 
angles  and  target  attitudes,  the  minimum  requirements  varies  from  15  to  73  nmi 
at  900  nmi  , 25  to  132  nmi  at  7,000  nmi  and  10  5 to  78  nmi  at  19,365  nmi 
If  the  current  baseline  Scanning  Laser  Radar  (SLR),  which  has  an  acquisition 
range  of  approximately  45  nmi  , were  employed  as  the  rendezvous  tracker,  the 
set  of  possible  transfers  would  be  significantly  constrained  as  a review  of 
Figures  7 2.4-18  through  7 2.4-30  indicates. 
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Table  724-1  Significant  Rendezvous  and  Docking  Parameters 


SUBMODULE 

PARAMETERS 

RENDEZVOUS  ACQUISITION 

TARGET  ALTITUDE 

TUG  ALTITUDE  DIFFERENCE  (aF) 

CENTRAL  ANGLE  {A£) 

RENDEZVOUS  TRACKER  ACQUISITION  RANGE 
RENDEZVOUS  TRACKER  FIELD  OF  VIEW 
TUG  NAVIGATION  DISPERSIONS 

TERMINAL  PHASE  INITIATION 

TPI s TPF  IMPULSE  BUDGETS 
MAIN  ENGINE  MODE 

MAIN  ENGINE  MODE  INITIALIZATION  TIME 
TUG  MANEUVER  RATE 
BURN  DURATION 

TERMINAL  PHASE  TRANSFER 

BURN  DISPERSIONS  (IMPULSE,  MISALIGNMENT) 

TRAJECTORY  TRIM  GATE  RANGE 

CLOSING  SPEED 

LOS  ANGULAR  RATE 

BRAKING  IMPULSE 

PRIMARY  BRAKING  GATE  RANGE,  IMPULSE 
SECONDARY  BRAKING  GATE  RANGE,  IMPULSE 
DOCKING  TRACKER  ACQUISITION  RANGE 
PHASE-PLANE  CONTROL  LAW 

DOCKING  INSPECTION  & ALIGNMENT 

SAFETY  SPHERE  RADIUS 
TELEVISION  DETAIL  DISCRIMINATION 
TELEVISION  FIELD  OF  VIEW 
DOCKING  TRACKER  FIELD  OF  VIEW 
DOCKING  TRACKER  SEARCH  CYCLE  RATE 
PHASE-PLANE  CONTROL  LAW 
RCS  IMPULSE  BUDGET 

DOCKING  CLOSURE 

DOCKING-AID  CONE  OF  VISIBILITY 
TELEVISION  FIELD  OF  VIEW 
DOCKING  TRACKER  FiEL-D«OF-VIEW 
DOCKING-AID  CONFIGURATION 
LATERIAL  CONTROL  STABILITY 
CONTACT  FORCE  REQUIREMENT 
CONTACT  ANGULAR,  DISPLACEMENT  TOLERANCES 
DOCKING  TRACKER  BLIND  RANGE 
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Table  7 2 4-2  Parametric  Relation  Example  Summary 


EXAMPLE  SUMMARY 


TARGET 

ALTITUDE 

(NM) 

EXAMPLE 
TPF  A V 
BUDGET 
(M/S) 

DIFFERENTIAL 

HEIGHT 

(NM) 

TRANSFER 
ANGLE 
(DCG)  - 

MINIMUM 
ACQUISITION 
RANGE  (NM) 

900 

l 

15 

10 

58  170 

15  24  5 ” 

-20 

103 170 

3349 

30 

140  170 

62  73 

7000 

10 

20 

48  170 
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40 

87  150 

60  87  * 

60 

119  150 

110 132 

19365 

5 

-10 

20  90 

10  5 15 
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20 
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Figure  72  4-6  Parametric  Relation  Between  Acquisition  Range  and  Time  lo  TP!  for  120  Degree  "transfers  from  Various-^ AH 
at  900  NMl  Altitude 
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Figure  72  4-7  Parametric  Relation  Betwdpn  Acquisition  Range  a\td  Time  to  TP!  for  140[Degree  Transfers  from  'Various  AH 
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Figure  724-17  Parametric  Relation  Between  Acquisition  Range  and  Time  to  Tt1lfor20  Degree  transfers  Rom  Various 
at  19365  NMI  Altitude 
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Figure  7 2 4-27  Parametric  Relation  Between  TPF  Velocity  Change  and  Optimal  Transfer  Arc  Length  at  19365  NM!  Altitude 
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Figure  724-29  Parametric  Relation  Between  Range  to  Target  at  TPF  and  Optimal  Transfer  Angle 
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Figure  7 2 4-30  Parametric  Relation  Between  Range  to  Target  at  TPF  and  Optimal  Transfer  Angle 


The  relation  between  any  impulse  budget  and  a candidate  rendezvous  tracker 
acquisition  range  is  important  and  should  be  reviewed  each  time  values  for 
either  parameter  are  being  evaluated  Peiteratmq  the  earlier  caution,  the 
Lambert  solutions  employed  in  developina  these  relations  were  optimal,, 
requiring  a minimum  impulse *wfth  approximately  equal  impulse  requirements 
at  TT I and  TPF  Non-optimal  transfers  require  somewhat  more  impulse  and 
exhibit  unequal  impulse  requirements  at  TPI  and  TPF  by  may  lower  the 
acquisition  range  required  for  a particular  transfer  without  significantly 
increasing  the  TPF  impulse  reauirerrenf  The  side  speeds  at  brakino  gates 
may  also  be  significantly  affected 

The  example  braking  gates,  shown  in  Figures  7 2 4-31  through  7 2 4-36,  illustrate 
the  complex  relation  between  orbital -dynamics  jodrameters  and  target-relative 
line-of-sight-  closing  speed  and  side  speed  Each  initial  starting  orbit,  as 
defined  by  differential  height,  seems  to  have  a best  transfer  angle,  i e.,  one 
yielding*  a minimum  side  sp'eed,  at  each  gdte*  But  that  transfer  arc  may  not  be 
attainable  within  the  impulse  budget  constraint  In  the  absence  of  a defini- 
tion of  how  much  side  speed  is  too  much,  these  charts  serve  to  characterize  the 
transfers  previously  constrained  by  impulse  and  acquisition  range  The  more 
general  relationships  between  range  and  the  closing  and  side  speeds  are 
illustrated  in  Figures  7 2 4-37  athrough  7 2 4-58  The  range  at  which  side 
speed  is-  a minimum  varies  as  a function  of  transfer .arc  indicating  fixed- 
range  braking  gates  may  not  be  the  best  braking  philosophy 

The  closing  speed's,  directed  along  the  instantaneous  line  of  sight,  in  all 
cases  were  inversely  related  to  the  transfer  angles  Closing  speed  tended  to 
decrease  with  range  but  significantly  only  for  cases  of  height  differentials 
of  20  nmi  or  less  and  at  target  altitudes  of  900  and  7000  nmi  (Figure 
7 2 4-37,  -39  and  -43)  These  indicated  that  braking  gates  could  be  placed 
economically  as  near  as  1 Km  to  the  Spacecraft 

Side  speed,  the  resultant  speed  normal  to  the  line  of  sight,  was  not  simply 
related  to  the  transfer  angle  Because  an  unsigned  magnitude  was  plotted,  some 
of  the  curves  folded  back  at  the  abscissa*  (Figure  7 2 4-38)  That  does -not 
significantly  impair  the  meaning  of  the  curves*  The  goal  was  identification 
of  transfer  angles  yielding  low  side-speed  components  during  the  final  10  Km 
(5  4 r\mi,)  of  closure  so  that  the  dynamics  to  be  encountered  during  braking 
could  be  understood. 

For  the  cases  at  a target  altitude  of  900  nmi  the  minima  occured  for  only 
one  transfer  angle  at  each  differential  height  60  degfee  transfer  yielded  the 
minimum  at  a range  of  5 Km  for  a AH  of  -16  nmi  , 100  degrees  at  2 Km  for  AH 
of  -20  nmi*  , and'  170  degrees*  at  1-5  Km  for  AH  of  -30  nmi  The  sidespeeds  for 
transfers  at  a target  altitude  of  7000  nmi  behaved  differently  as  the  transfer 
angle  was  varied  (Figure  7 2-7-44,  -46,-  and'  -48)  When  the  Tug  closed  from 
differential  heights  of  -20  nmi  and  -40'  nmi  , aTT  the  transfers  plotted 
yielded  sid’espeed  minimum  of  less-  than  0 025  m/s  but  at-  different  ranges  The 
90  and  100  de’gree  transfers'  from  a AH  of  -20  nmi  seem  to  yield  the  lowest 
average  si*de  speed  Fora  aH  of  -40  nmi  , the  same  two  transfer  angles  yielded 
side  speeds  below  0‘  05  m/s  for  ranges  between  7 and  3 Km,  but  transfers  of  120 
degrees  from  both  -20  nmi  and  -40  nmi  height  differentials  exhibited  con- 
tinuously diminishing  si  despeed’^unti  1 -minima  occurred  at  ranges  of  1 Km  "The 
lowest  side  speed  for  an*  initial  height  difference  of  -60  nmi  also  occurred 
during*  the  closure  along  the  120  degree  arc 
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Figure  724-31  Parametric  Relation  Between  Transfer  Angle  and  Closing  and  Side  Speeds  at  an  Example  Braking  Gate 
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Figure  72  4-33  Parametric  Relation  Between  Optimal  Transfer  Angle  and  Closing  and  Side  Speeds  at  en  Example  Braking  Gate 
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Figure  7 2 4-35  Parametric  Relation  Between  Optimal  Transfer  Angle  and  Closing  and  Side  Speeds  at  an  Example  Braking  Gate 
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Figure  7 2 4-36  Parametric  Relation  Between  Optimal  Transfer  Angle  and  Closing  and  Side  Speed  at  an  Example  Braking  Gate 
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KM  - RANGE  TO  TARGET  SPACECRAFT 

Figure  A2  4-41  Parametric  Relation  Between  Closing  Speed  and  Range  for  Various  Transfers  from  -30  NMI  AH  a?  900  NMI  AL  TfTUDE 
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Figure  72  4-42  Parametric  Relation  Between  Side  Speed  and  Range  for  Various  Transfers  from  -30  NMI  AH  at  900  NM!  Altitude 
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KM  - RANGE  TO  TARGET  SPACECRAFT 

Figure  7 2 4-43  Parametric  Relation  Between  Closing  Speed  and  Range  for  Various  Transfers  from  - 20  NM!  AH  at  7000  NM!  Altitude 
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Figure  7 2 4-44  Parametric  Relation  Between  Side  Speed  and  Range  for  Various  Transfers  from  -20  NM!  AH  at  7000  NM!  Altitude 
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Figure  7.2  4-46  Parametric  Relation  Between  Side  Speed  and  Range  for  Various  Transfers  from  -40  NMI  AH  at  7000  NMI  Altitude 
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Figure  7 2 4-47,  Parametric  Relation  Between  Closing  Speed  and  Range  for  Various  Transfers  from  - 60  NMI  AH  at  7000  NM!  Altitude 
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KM  - RANGE  TO  TARGET  SPACECRAFT 

Figure  7 2 4-48  Parametric  Relation  Between  Side  Speed  and  Range  for  Various  Transfers  from  - 60  NMI  *A  H at  7000  NMI  Altitude 
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Figure  7 2 4-49  Parametric  Relation  Between  Closing  Speed  and  Range  for  Various  Transfers  from  -10  NMI  AH  at  19365  NMI  Altitude 
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Figure  724-50  Parametric  Relation  Between  Side  Speed  and  Range  for  Various  Transfers  from  -10  NMI  AH  at  19365  NMI  Altitude 
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NMi  AH  at  19365  NMI  Altitude 
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TARGET  ALTITUDE  = 19365  NMI 
TUG  INITIAL  AH  = -30  NMI 


Figure  72  4-53  Parametric  Relation  Between  Closing  Speed  and  Range  for  Various  Transfers  from  -30  NM!  AH  at  19365  NMI  Altitude 
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Figure  724-54  Parametric  Relation  Between  Side  Speed  and  Range  for  Various  Transfers  from  -30  NMI  AH  at  19365  NMI  Altitude 
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The  cases  at  19265  nmi  , slight,  but  not  significantly,  above  equatorial 
geosynchronous  altitude,  all  yielded  lower  side-speeds  than  the  other  altitudes 
analyzed  (Figure  7 2 4-50,  -52,  -54,  -56  and  -58)  For  initial  height 
differentials  of  -10  nmi  and  -20  nmi  , rolling  minimal  somewhat  like  those 
at  7000  nmi.  v/ere  evident  The  transfers  yieldmq  the  lowest  side-speed 
appeared  to  be  80  degrees  from  -10  nmi  , and  50  degrees  from  -20  nmi  The 
curve  natures  were  different  for  transfers  from  differential  heights  of 
-30  nmi  , -40  nmi  , and  -50  nmi.  The  side-speed  increased  as  ranqe  decreased 
The  least  side-speeds  resulted  from  80  degree  transfers  from  -3J)  nmi  and 
-50  nmi  and  90  degrees  from  -40  nmi  A representative  lateral  deadband  mag- 
nitude is  0 07  m/s  and  this  can  be  used  to  evaluate  the  side-speed  magnitudes 

725  Observations  and  Conclusions 

The  operational  flow  and  the  resultant  parametric  relations  are  intended  to  be 
data  for  use  in  understanding  the  constraints  on  rendezvous  and  docking,  for 
developing  rendezvous  targetting  philosophy,  and  fop  understanding  the  effect 
of  rendezvous  targetting  on  the  docking  variables 

No  docking  parametric  relations  were  developed  because  of  the  lack  of  a Tug 
simulator  incorporating  a slosh  model 

However,  some  preliminary  assessment  of  rendezvous  parametric  relations  is 
possible  The  baseline  tracker  acquisition  range  is  possibly  inadequate  for 
pre-TPI  acquisition  Small  navigation  dispersions  andTPI  impulse  budgets 
larger  than  the  examples  may  ease  the  requirement  for  longer  acquisition  ranges 
' but  additional  analysis  is  required 

Analysis  of  non-optimal  Lambert  transfers  should  be  undertaken  as  soon  as 
possible  because  that  class  is  possibly  more  likely  than  optimal  transfers. 

The  APS  impulse  budget  for  rendezvous  and  docking  appears  to  drive  the  ren- 
dezvous tracker  acquisition  range  requirement  Additional  and  continuing 
refinement  of  the  impulse  budget,  therefore,  is  required 

The  implementation  of  the  final  braking  before  Docking  Inspection  and  Align- 
ment commences  may  be  implemented  under  phase-plane  control,  i e , a smoothe 
distributed  impulse  range-rate  solution  rather  than  a discrete  burn  As 
mentioned  previously,  the  feasibility  of  this  approach  must  be  defined  with 
more  sophisticated  techniques  than  were  employed  in  this  study 

A detailed  simulation  of  Tug  body  dynamics  during  docking  to  assess  the  effects 
of  slosh  on  APS  fuel  usage  and  the  effect  of  impact  dynamics  on  Tug  trans- 
lational and  rotational  control  is  required  to  support  analysis  of  the  docking 
parameters 
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FLIGHT  OPERATIONS  SUPPORT  ANALYSIS 


During  the  IUS/Tug  time  frame,  NASA's  Spaceflight  Tracking  and  Data  Network 
(STDN)  will  consist  of  two  subnets  the  Tracking  and  Data  Relay  Satellite 
System  (TDRSS)  subnet  and  the  STDN  ground  site  subnet  The  TDRSS  will  provide 
two  Tracking  and  Data  Relay  Satellites  (TDRS)  plus  a TDRSS  ground  terminal 
The  post-1979  ground  site  subnet  will  be  composed  of  six  to  eight  sites  from 
the  STDN.  Ground  sites  are  currently  planned  at  the  following  locations 
Goldstone,  Madrid,  Orroral , Fairbanks,  Merritt  Island  (launch  only),  Rosman, 
Bermuda  (launch  only),  and  Tananarive  (launch  only) 

The  major  functions  of  the  STDN  are  to  (1)  track  Spacecraft  and  relay 
launch  and  trajectory  data  in  real-time  from  Spacecraft  to  control  centers, 

(2)  relay  commands  from  control  centers  to  Spacecraft,  (3)  relay  telemetry  and 
TV  signals  both  in  real-time  and  in  store-and-forward  modes  from  Spacecraft 
to  control  center,  (4)  relay  voice  communications  between  control  centers  and 
Spacecraft,  and  (5)  augment  recovery  communications,  as  required 

Although  the  present  network  provides  sophisticated  tracking  and  data  acquisition 
support  to  earth-orbiting  Spacecraft,  it  does  have  such  limitations  as  Space- 
craft access  time,  geographic  coverage,  and  information  bandwidth  These 
limitations,  in  turn,  impose  design  and  operational  constraints  on  the  user 
Spacecraft  To  reduce  these  limitations,  as  well  as  to  minimize  the  overall 
cost  of  tracking  and  data  acquisition,  NASA  has  been  studying  the  use  of  a 
Tracking  and  Data  Relay  Satellite  System  (TDRSS)  to  augment  the  STDN 

The  TDRSS  (see  Figure  8 0.0-1)  consists  of  two  geosynchronous  satellites, 
approximately  130  degrees  apart  in  longitude,  which  will  relay  tracking, 
telemetry,  and  command  data  between  low  earth-orbiting  user  Spacecraft 
(<1200  Km),  and  a ground  terminal  located  in  the  continental  United  States 
This  concept  also  provides  for  two  spare  satellites,  one  in  orbit,  and  the  other 
in  configuration  for  a rapid  launch  A "bent-pipe"  concept  is  used  in  the 
design  of  the  telecommunications  service" system  (i~e  , all  communication  signals 
received  at  the  Tracking  and  Data  Relay  Satellite  (TDRS)  are  translated  in 
frequency  and  retransmitted),  making  possible  almost  continuous  reception  of 
data  in  real  time 

8 1 STDN/TDRSS  DATA  FLOW 

The  data  flow  from  the  STDN  and  TDRSS  is  illustrated  in  Figure  8 1 0-1 
Several  paths  are  available  to  the  user,  dependent  on  which  subnet  of  the  STDN 
is  being  utilized  If  the  user  is  transmitting  data  to  either  of  the  two  TDRSS 's, 
a direct  flow  is  available  to  the  White  Sands  ground  station.  The  ground 
station  will  also  function  as  a bent  pipe  repeater  and  process  the  data  only  to 
the  extent  that  it  is  acceptable  to  the  NASCOM  interface  NASCOM  in  this 
instance  can  provide  land  line  capabilities  up  to  1 3 Mbps  Domestic  satellites 
are  also  being  considered  which  will  provide  up  to  a 50  Mbps/transponder 
capability  from  the  TDRSS  ground  station  to  the  user 

If  the  STDN  subnet  is  used,  several  possibilities  exist  Data  acquired  by  the 
sites  located  within  the  continental  United  States  will  be  processed  to  inter- 
face with  NASCOM  Definition  of  the  NASCOM  capabilities  for  the  Shuttle  era 
has  not  been  presented,  however,  a single  land  line  capability  will  be 
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Figure  8 00-1  STDtJ  and  TDRS  Subnets 


available  for  1 3 Mbps  NASCQM  capability  from  the  remote  site  is  even  more 
loosely  defined  Presently,  a 21  2 Kbps  capability  exists  at  the  STDN 
stations  The  Deep  Space  Network  (DSN)  and  Fairbanks  (ULA)  have  a wideband 
circuit  to  GSFC  capable  of  28  5 Kbps  Rosman  has  a 1 5 MHz  circuit  to  GSFC 
This  may  be  increased  by  the  use  of  satellite  communications  or  other  NASCOM 
enhancements  It  is  expected  that  data  from  the  STDN  will  be  routed  to  GSFC, 
GSFC  in  turn  will  act  as  a switching  and  distribution  center  to  re-route  the 
data  to  the  users 

81.1  STDN/TDRSS  Telemetry  Data  FLow  and  Processing 

It  is  planned  that  both  subnets  will  present  the  same  interface  to  the  STDN 
user  and  both  can  provide  telemetry,  command,  and  tracking  to  any  user  The 
capabilities  planned  at  the  STDN  subnet  interface  have  not  been  defined  at 
this  time 

8111  TDRS  Telecommunications  Links 

The  concept  of  the  TDRS  telecommunications  links  is  explained  below  as  a basis 

for  TM  data  flow  and  processing  (reference  Figure  8 1 1-1) 

The  telecommunications  link  from  the  ground  terminal  to  the  TDRS  to  user  is 
called  the  forward  link,  and  the  link  from  the  user  to  TDRS  to  the  ground  is 

called  the  return  link  The  forward  links  carry  user  command  data,  tracking 

signals,  and  voice  transmissions,  and  the  return  links  carry  user  telemetry 
data,  return  tracking  signals,  and  voice  Both  the  forward  and  return  links 
consist  of  two  segments 

• Space-to-Space  Link  - This  is  defined  as  the  link  between 
the  TDRS  and  the  user  Spacecraft 

• Space- to-Ground  Link  - This  is  defined  as  the  link  between 
the  TDRS  and  the  TDRSS  ground  terminal 

Each  TDRS  contains  the  following  antennas  to  support  the  space-to-space 
communication  links  and  the  space-to-ground  communication  links 

• Space-to-Space  Communication  Links  - 

(1)  One  40-element,  S-band  antenna  system  10  elements  are 
used  to  support  the  forward  link,  the  remaining  30  elements  are 
used  as  an  array  antenna  to  support  the  return  (telemetry)  link 
of  20  users  simultaneously  This  antenna  system  is  called  the 
Multiple-access  (MA)  system,  user  Spacecraft  supported  on  this 
system  are  called  MA  users 

(2)  Two  3 8-meter  parabolic  antennas  operating  at  S-  and  Ku-bands 
Each  antenna  system  is  called  a Single-access  (SA)  system  because 
each  antenna  normally  will  support  one  user  at  a time  However, 
each  antenna  can  support  two  users  simultaneously  (one  at  S-band 
and  one  at  Ku-band)  provided  both  users  are  within  the  beamwidth 
of  the  antenna  The  user  Spacecraft  supported  on  these  antennas 
are  called  S-band  Single-access  (SSA)  users  or  Ku-band  Single- 
access (KSA)  users 
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Figure  8 1.1-1.  Two  Satellite  TDRSS  Concept 

• Space-to-Ground  Communication  Links  - One  1 8 meter,  parabolic 
Ku-band  antenna 

8 1.1  2 TDRS  Users 

The  users  of  the  TDRSS  are  classified  by  the  type  of  service  they  require 
from  the  system. 

• Multiple  Access  User  - The  MA  user  is  an  S-band  user  serviced 

by  the  TDRS  phased  array.  The  maximum  return  link  bit  rate  under 
most  circumstances  is  100  Kbps 

• S-Band  Single  Access  User  - The  SSA  user  is  serviced  by  one  of  the 
3 8 meter  parabolic  antennas  on  the  TDRS  The  return  link  bit 
rates  can  vary  from  1 Kbps  to  6 Mbps 

• Ku-Band  Single  Access  User  - The  KSA  user  is  serviced  by  one  of 
the  3 8 meter  parabolic  antennas  on  the  TDRS.  The  maximum  band- 
width is  225  MHz,  thereby  providing  a 150  Mbps  biphase  or  a 300 
Mbps  quadriphase  bit  rate  on  the  return  link 

8113  TDRS  Telemetry  Flow 

Two  of  the  three  user  services  provided  by  the  TDRS,  MA,  and  SSA  are  explained 
in  further  detail  in  the  following  paragraphs.  The  Single  Access  Ku-band 
system  capability  far  exceeds  Tug  requirements  at  this  time 
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Each  TDRS  will  be  designed  to  support  a minimum  of  20  MA  users  simultaneously 
The  multiple  access  system  employs  a 30-element  S-band  phased  array  antenna 
to  minimize  onboard  complexity  Adaptive  beam  forming  functions  are  performed 
at  the  ground  station  The  MA  link  performance  for  each  user  is  a function 
of  the  number  of  MA  users  within  view  of  the  TDRS,  their  data  rates,  and 
power  outputs 

Each  user  may  have  a different  data  rate  The  average  user’s  raw  real-time  data 
rate  is  11  5 Kbps  plus  overhead  (approximately  10  percent)  or  approximately 
12  7 Kbps  To  this,  each  user  spacecraft  may  add  15  percent  for  the  trans- 
mission of  data  stored  onboard  during  the  blind  period,  thereby  yielding  an 
average  rate  of  14  6 Kbps  The  total  data  rate  for  20  users  plus  overhead  is, 
therefore,  approximately  292  Kbps  From  time  to  time,  users  in  the  system 
will  change  as  new  Spacecraft  are  launched  and  old  ones  are  discontinued 
Data  rates  may  increase  up  to  25  percent  on  the  average  for  the  projected 
system  The  total  bit  rate  from  the  S-band  array  may,  therefore,  be  projected 
as  high  as  365  Kbps  through  the  ground  links 

The  TDRS  SSA  return  link  includes  two  3 8 meter  antennas  steerable  by  ground 
command  Autotrack  capability  does  not  exist  due  to  weight  considerations 
The  SSA  service  provides  a 10  MHz  receive  bandwidth  and  throughput  capability 
of  1 Kbps  to  6 Mbps  The  10  MHz  bandwidth  is  sufficient  to  accommodate  video, 
however,  no  provisions  are  made  at  this  time  to  accommodate  video  data  at  the 
TDRS  ground  station 

SSA  and  MA  return  link  data  is  frequency  translated  onboard  the  TDRS  for 
transmission  to  the  ground  in  the  Ku-band  frequency  range 

8114  TDRS  Ground  Terminal 

The  TDRS  ground  terminal  provides  three  primary  services  (1)  forward  user 
commands  to  the  TDRS  for  transmission  to  user  spacecraft,  (2)  receive  user 
TM  and  provide  the  NASCOM  interface  for  transmission  to  the  user,  and 
(3)  receive  Range  and  Range  Rate  data  as  an  input  to  the  6SFC  orbit  deter- 
mimtation  system 

The  ground  terminal  will  be  capable  of  receiving  and  handling  downlink  data 
from  20  MA  users,  6 KSA  users,  and  6 SSA  users  simultaneously.  However,  for 
the  SA  systems  only  4 KSA  and  4 SSA  data  streams  from  the  two  operational 
Spacecraft  will  normally  be  scheduled  The  ground  terminal  will 

a Receive  the  return  links  from  the  two  operational  TDRSs  The 

receiving  system  is  designed  to  provide  a sufficient  signal  margin 
for  reliable  contact  between  the  satellites  and  the  ground  terminal. 

b Demultiplex  the  received  signals  to  recover  user  Spacecraft  data 
and  ranging  data 

c.  Generate  the  proper  PN  codes  for  extracting  range  information, 
and,  in  the  case  of  the  MA  users,  uniquely  identifying  each  of  20 
user  Spacecraft 
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d Demodulate  the  received  user  Spacecraft  telemetry  in  accordance 
with  the  modulation  technique  used 

e.  Bit  synchronize,  and  decode  the  user  telemetry  in  such  a manner  to 
interface  with  NASCOM  for  transmission  to  the  appropriate  user 
control  center  and/or  the  data  processing  system  at  GSFC,  or  other 
non-GSFC  locations 

The  content  of  user  Spacecraft  telemetry  will  not  be  monitored  or  altered  at 
the  ground  terminal.  It  will  be  routed  via  NASCOM  to  the  appropriate  user 
control  and  data  processing  facility.  Presently,  all  data  will  be  routed  to 
the  user  as  it  is  acquired  by  the  TORS  ground  station  in  a real  time  mode 
On-site  storage  capability  for  store  and  forward  is  not  being  planned 
Because  users  of  the  TDRSS  are  divided  into  primary  categories,  MA  and  SA 
users,  the  methods  of  ground  data  handling  will  be  somewhat  different 

The  MA  user  channels  are  recovered  by  demultiplexing  the  converted  Ku-band 
return  link  from  the  TDRS  A signal  to  interference  ratio  can  be  established 
for  each  MA  user  by  combining  signals  received  from  the  various  elements  of 
the  MA  antenna  array  in  the  proper  magnitude  and  phase  The  SSA  channels  are 
also  recovered  from  the  converted  Ku-band  signal  Beam  forming  is  not 
necessary  for  SSA  user  signals. 

812  STDN/TDRSS  Tracking  Modes  and  Processing 

The  TDRSS  ground  terminal  is  assigned  to  be  furnished  with  a single  tracking 
data  processing  system  providing  both  high  and  low  rate  sample  range  and 
range  rate  (R&RR)  data  for  all  Spacecraft  tracked  via  TDRSS  in  a standard 
format.  The  estimated  maximum  data  rate,  including  transmission  overhead,  is 
4 8 Kbps  This  channel  will  be  active  almost  continuously  and  at  present  is 
considered  to  be  routed  through  to  the  GSFC  orbit  computation  center,  but  also 
may  be  bridged  to  other  locations. 

The  user  MA  system  must  be  capable  of  providing  PN  code  coherence  so  that 
ranging  computations  can  be  performed  on  the  ground  Because  PN  code  modu- 
lation is  used  in  both  forward  and  return  links,  a PN  code  synchronization 
must  be  established  before  any  functions  can  be  performed.  After  synchro- 
nization, data  can  be  transmitted  in  both  directions  Ranging  is  accomplished 
by  computing  the  transit  time  of  the  signal  from  TDRS  to  user  to  TDRS 

The  ranging  subsystem  accepts  digital  R&RR  data  from  the  RF  system  MA  and  SA 
demodulators  and  processes  it  for  delivery  to  the  Orbit  Determination  System 
(ODS)  via  the  NASCOM  interface  It  also  accepts  TDRS  R&RR  data  from  the  RF 
system  bilateration  correlator,  or  alternatively,  from  the  S-band  backup 
system  TDRS  demodulator  The  ranging  subsystem  uses  this  data  m two  ways 
First,  it  processes  the  data  for  delivery  to  ODS  via  the  NASCOM  interface 
Also,  it  performs  some  on-site  calculations  to  provide  ranging  information 
to  the  attitude  and  stationkeeping  processor 

TDRSS  tracking  capability  can  be  summarized  in  the  following  manner  User 
satellite  position  in  near  polar  orbits  can  be  determined  to  an  uncertainty 
of  60  meters  and  accuracy  is  degraded  as  the  user  inclination  approaches  that 


of  the  TORS  Tracking  accuracy  is  dependent  on  the  length  of  the  data  arcs 
and  the  number  of  supporting  TDRSs  (1  or  2). 

The  TDRSS  is  expected  to  provide  three  types  of  user  services  The  first  two 
services  are  defined  for  information;  the  third  for  its  applicability  to  Tug 

• Routine  Orbit  Determination  - Necessary  only  to  establish  orbits 
sufficient  to  predict  future  satellite  position  for  acquisition 
by  ground  station  and  TDRSS  and  for  network  scheduling  data 

• Precision  Orbit  Determination  Accuracy  - Necessary  for  satellite 
systems  to  properly  analyze  and  evaluate  sensor  data  Requirements 
today  exist  for  100  meters  or  less  Future  requirements  may  be  more 
stringent 

• Real  Time  Orbit  Determination  - Accuracy  necessary  for  those 
satellite  subsystems  which  must  execute  maneuvers  and  guarantee 
Spacecraft  and/or  Shuttle  crew  safety  Accuracy  requirements  will 
vary  dependent  on  mission,  however,  short  data  arcs  taken  in  a 
limited  amount  of  time  will  be  the  rule  of  the  day 

813  STDN/TDRSS  Command  Flow  and  Processing 

The  TDRSS  forward  link  (command)  is  characteristically  described  by  the  type 
of  user  - single  access  or  multiple  access 

The  MA  command  channel  of  the  TDRS  radiates  via  the  10  element  transmit  array 
The  MA  uplink  is  a single  frequency  time  division  system  with  the  capability 
to  command  only  one  MA  user  at  a time  The  user  will  interface  with  the  TDRS 
ground  terminal  The  ground  terminal  will  provide  the  proper  scheduling  and 
support  element  selection  (antennas,  transmitters,  carrier  modulation,  etc  ,) 
to  the  user  To  be  consistent  with  the  throughput  philosophy  of  the  TDRSS 
user,  commands  will  be  generated,  transmitted,  executed,  and  verified  by  the 
applicable  user  control  center  The  forward  link  will  support  MA  user  require- 
ments up  to  10  Kbps  Uplink  commands  from  the  user  control  center  will  be  in 
a real  time  mode  only,  command  storage  and  load  capability  does  not  exist  at 
the  ground  station 

The  SSA  forward  link  user  can  operate  in  a narrowband  or  wideband  (under 
consideration)  mode  Uplink  data  rates  are  variable  from  100  bps  to  500  Kbps 
Operational  considerations  for  the  SSA  forward  link  are  similar  to  the  MA 
characteristics  of  the  last  paragraphs 

8 2 NETWORK  CHARACTERISTICS  AND  CONFIGURATION 

The  eight  station  STDN  subnet  and  single  TDRS  ground  station  comprise  the  STDN. 
As  part  of  the  STDN,  operational  control  of  the  TDRSS  ground  terminal  will  be 
exercised  by  the  Network  Operations  Control  Center  (NOCC)  The  NOCC  will  send 
the  ground  terminal  a weekly  user  support  schedule  via  NASCOM  The  schedule 
will  specify  the  support  times,  user  Spacecraft  frequencies,  and  Acquisition  of 
Signal /Loss  of  Signal  (AOS/LGS)  times.  This  basic  support  schedule  will  be 
used  to  generate  a detailed  TDRSS  utilization  schedule,  i.e  , an  activity  plan 
Other  inputs  to  the  activity  plan  will  include  (a)  user  and  TDRS  data,  (b) 
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ground  terminal  status,  and  (c)  other  required  TDRS  commands.  The  same  types 
of  utilization  schedules  are  expected  to  be  provided  to  the  eight  STDN  stations. 

The  STDN  is  configured  to  provide  two  types  of  support  (1)  launch  support 
and,  (2)  high  altitude  satellite  support  The  launch  support  stations  will 
be  configured  and  scheduled  for  that  express  purpose  Even  though  the 
support  configuration  has  not  been  finalized,  it  is  expected  that  the  launch 
stations  will  not  have  the  full  capability  of  the  other  STDN  stations 
Fairbanks  will  provide  support  to  the  high  inclination  orbits,  while  Orroral , 
Madrid  and  Goldstone  will  be  significant  to  those  missions  requiring  support 
characteristics  of  the  Deep  Space  Network  (DSN) 

The  STDN  and  TDRSS  significantly  differ  in  their  design  and  support  concepts. 

It  follows  then  that  their  operational  constraints  are  different, 

8.2  1 STDN  Network  Operational  Constraints 

The  STDN  will  function  primarily  as  a high  altitude  mission  support  network, 
and  operational  support  constraints  will  be  described  as  they  relate  to  these 
objectives. 

Keyhole  Considerations  - The  STDN  will  probably  utilize  one  or  more  of  the 
three  basic  S-band  antenna  systems,  the  9 meter  (30'),  12  meter  (40'),  or 
26  meter  (85 1 ) parabolic  dish  These  antenna  systems  utilize  an  X-Y  mount. 

The  X-Y  mount  application  is  used  because  zenith  coverage  is  accomplished 
which  is  not  possible  with  the  convent! a!  Az-EL  mount  The  X-Y  mount  is 
capable  of  tracking  through  zenith  but  has  a gimbal  restriction  keyhole  near 
the  horizon.  The  restriction  is  generally  oriented  north  to  south  on  the  9 
meter  systems  and  east  to  west  on  the  26  meter  systems  (Figure  8. 2. 1-1). 

Signal  loss  is  most  significant  during  low  altitude  missions  and  becomes  less 
significant  as  altitude  increases  In  the  past,  losses  up  to  a 15  degree 
antenna  elevation  angle  has  occurred.  Additional  time  may  be  required  during 
a pass  to  re-acquire  phase  lock  once  the  vehicle  has  passed  through  the  keyhole 

Terrain  Features  - In  addition  to  the  keyhole  effect,  S-band  antenna  system 
performance  will  be  degraded  by  terrain  features,  i e.,  mountainous  terrain 
Obviously,  this  is  related  to  station  location. 

Attitude  Considerations  - The  onboard  S-band  phased  array  antenna  will  have  a 
limited  beamwidth  To  maintain  satisfactory  communications  with  the  ground 
stations  at  acceptable  gains  and  bit  error  rates,  the  attitude  and  pointing  of 
the  vehicle  will  be  restricted. 

Handover  Considerations  - At  altitudes  above  6500  KM,  the  STDN  should  be  able 
to  provide  continuous  coverage  of  the  vehicle.  During  this  time  period  signal 
losses  during  handover  should  be  minimal,  since  downlink  lock  can  be  established 
by  more  than  one  station.  Handover  becomes  primarily  procedural.  If  handover 
is  complicated  by  vehicle  attitude  constraints,  ground  terrain  features,  or  the 
keyhole  effect,  then  the  signal  loss  may  be  more  significant. 

STDN  Ground  Station  Configuration  - The  STDN  will  be  configured  to  primarily 
provide  support  to  high  altitude 'missions  Three  stations,  MILA,  BDA,  and 
TAN  are  configured  for  launch  support  only,  and  manning  levels  for  these 
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Figure  8 2 1-1  S-Band  Antenna  Keyholes 


stations  will  be  based  on  a single  shift  operation  Four  to  five  stations 
remain  for  orbital  support  Fairbanks  (ULA)  will  not  provide  meaningful 
low  earth  orbit,  low  inclination  support  Hence,  the  STDN  is  reduced  primarily 
to  a four  station  network  which  is  not  capable  of  or  designed  for  significant 
low  altitude  support 

8 2.2  TDRSS  Network  Operational  Constamts 

The  TDRSS  will  function  as  the  low  altitude  mission  support  subnet,  and  its 
primary  operational  constraints  are  as  follows 

Handover  Considerations  - Assuming  the  vehicle  has  only  one  S-band  antenna, 
three  types  of  handovers  must  be  considered  (1)  vehicle  to  TDRS-E  or  TDRS-W, 
(2)  TDRSS  ground  antenna  switching,  and  (3)  possible  handover  to  and  from  the 
STDN. 

Positional  location  of  the  vehicle  S-band  antenna  will  be  signficant  because  of 
(1)  the  need  to  slew  the  onboard  antenna  from  one  TDRS  to  another,  and  the 
associated  antenna  slew  times,  and  (2)  the  possible  need  for  vehicle  attitude 
changes  to  ensure  communications 

Of  less  significance  will  be  the  switching  of  the  data  source  from  one  TDRS 
ground  antenna  to  another  as  an  input  to  the  ground  station  data  handling 
system 
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Handovers  from  one  subnet  to  another  subnet  may  result  in  signal  losses,  again 
dependent  on  the  geometry  involved  relative  to  the  vehicle,  TDRS  and  STDN. 

The  following  paragraphs  will  further  explain  the  possible  problems 

TDRS  Earth  Occultation  - The  TDRS  consists  of  two  active  geosynchronous 
satellites  130  degrees  apart  m longitude  on  station  over  the  equator.  The 
two  active  satellites  do  not  provide  full  orbital  coverage  of  the  user  vehicle 
due  to  earth  occultation  Communications  interruptions  occur  in  what  is 
termed  the  "zone  of  exclusion",  with  Its  cause  and  location  illustrated  m 
Figure  8 2.2-1  The  zone  of  exclusion  represents  the  lower  altitude  coverage 
limits  for  the  TDRSS  users,  which  is  less  than  1200  kilometers.  The  amount 
of  coverage  provided  to  a user  spacecraft  is  a function  of  the  user'  altitudes 
and  inclinations.  User  at  low  altitudes  and  inclinations  will  pass  through 
the  zone  of  exclusion  on  each  orbit  and  receive  the  least  coverage  However, 
users  at  higher  altitudes  and  inclinations  will  pass  through  the  zone  of 
exclusion  only  periodically,  e g.,  a user  at  1000  kilometers  altitude  and  99 
degrees  inclination  will  pass  through  the  zone  of  exclusion  once  per  day  or 
less 

Tug  Antenna  Occultation  Considerations  - Vehicle  antenna  masking  could  be  caused 
by  the  vehicle  structure  occulting  the  S-band  antenna  and  the  TDRS.  This 
situation  may  occur  if  the  space  vehicle  is  held  in  an  attitude  with  at  least 
two  axis  fixed  over  an  extended  period  of  time 

User  Coverage  Constraints  - The  user  can  be  provided  with  100  percent  coverage 
at  altitudes  greater  than  1200  KM.  Twelve  hundred  kilometers  represent  the 
lower  coverage  limits  of  the  TDRSS  The  upper  coverage  limits  for  the  single 
and  multiple  access  systems  are  12,000  KM  and  2000  KM,  respectively.  A summary 
of  the  TDRSS  orbital  coverage  follows 

• Multiple-access 

(1)  Minimum  coverage  at  200  kilometers 

(2)  100  percent  coverage  between  1200  and  200  kilometers 

(3)  Coverage  decreases  towards  zero  for  synchronous  altitudes. 

* Single-access 

(1)  Minimum  coverage  at  200  kilometers. 

(2)  100  percent  coverage  between  1200  and  12,000  kilometers 

(3)  Coverage  decreases  towards  zero  at  synchronous  altitudes 

8 3 SPACE  TUG  MISSION  COMMUNICATIONS  ANALYSIS 

Three  representative  Tug  missions  were  baselined  for  a network  support  study. 
Orbital  trajectories  were  calculated  for  interplanetary,  sun  synchronous,  and 
geosynchronous  missions,  and  line  of  sight  geometric  support  by  the  STDN  and 
TDRSS  was  assessed.  In  the  initial  assessment,  all  STDN  sites  were  included, 
to  provide  a confidence  that  useful  stations  were  not  prematurely  discarded. 
Table  8. 3. 0-1  illustrates  possible  mission  support  by  percentage  of  mission 
time. 
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Table  8.30-1.  STDN/TDRSS  Station  Coverage 


NASA 

MISSION 

INTERPLANETARY 

SUN 

SYNCHRONOUS 

GEOSYNCHRONOUS 

DELIVERY 

MISSION 

LENGTH 

(DAYS) 

I 27 

0 62 

2 39 

MIL  * 

8 4 

6 6 

40  8 

ROS  * 

4 9 

7 8 

40  8 

BDA 

4 0 

6 5 

40  8 

t 

MAD  * 

0 7 

1 9 

40  8 

STATION 

ACQUISITION 

CYI 

2 6 

0 

40  8 

ACN 

I 4 

0 

41  1 

PERCENTAGE 
OF  TOTAL 
MISSION 
TINE 

TAN 

18  3 

6 8 

8 4 

ORR  * 

64  9 

3 1 

17  4 

GWM 

52  0 

1 3 

17  4 

HAW 

46  9 

2 5 

7 1 

ULA  * 

0 

5 7 

0 

GDS  * 

23  8 

5 3 

40  8 

QUI 

19  9 

5 9 

40  8 

AGO 

22  9 

4 8 

41  1 

TDRS-E 

49  7 

84  6 

15  0 

TDRS-W 

44  9 

67  4 

12  5 

*Planned  ground  stations 

Generalized  ground  support  requirements  for  each  phase  of  the  Tug  missions 
are 


"^sPhase 
Req 'mt*'*'^ 

Orbital  Checkout 
Deployment,  Coast, 
Midcourse  Corrections 

Burn  Phases 

Payload  Delivery,  Rendz. 
& Docking,  Visual  C 0 

Telemetry 

16  Kbps 

64  Kbps 
256  Kbps 
(Received) 

16  Kbps 
64  Kbps  TV 

Command 

2 Kbps 

2 Kbps 

2 Kbps 

Tracking 

No  Requirement 

No  Requirement 

No  Requirement 
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831  Sun  Synchronous  Mission  Coverage 

The  sun  synchronous  mission  was  analyzed  for  0 62  days  in  length  The  ascent 
burn  delivered  the  vehicle  to  an  altitude  of  920  nautical  miles  where  a cir- 
cularization burn  placed  the  vehicle  into  a circular  orbit  The  mission 
coverage  indicated  is  from  TDRS-E,  TDRS-W  and  the  three  station  ground  network 
composed  of  Goldstone,  Orroral  and  Madrid 

Figure  8 3 1-1  is  a timeline  of  mission  events  and  composite  AOS/LOS  of  the 
TDRS's  and  STDN  stations  AOS/LOS  and  mission  events  are  also  shown  in  per- 
spective on  the  mission  trajectory  traces  in  Figure  8.3  1-2  and  8.3  1-3  Only 
pertinent  orbits  are  shown  to  maintain  simplicity  and  ease  of  understanding 
The  following  conclusions  are  based  on  the  known  support  periods,  support 
station  capabilities,  and  onboard  system  output  rates 

• The  STDN  does  not  provide  any  coverage  during  three  critical  mission 
time  periods,  ascent  burn,  circularization  burn,  and  the  retro  burn. 

• The  TDRS  can  provide  support  for  all  burn  periods. 

• The  STDN  will  augment  the  TDRS  only  during  one  time  period,  after 
retro  burn  and  before  circularization  burn  Because  of  the  high 
vehicle  altitude,  Orroral  can  provide  limited  coverage 

• The  TDRS  provides  the  necessary  low  altitude  support  for  which  it 
was  designed,  adequately.  The  STDN  is  not  required  for  low-earth 
orbit  support. 

• If  the  Tug  outputs  data  at  64  Kbps  or  higher  (possibility  256  Kbps) 
during  burn  periods  and  the  recorder  dump  periods,  the  MA  system  will 
not  sufficiently  support  the  Tug  and  other  users.  This  will  necessi- 
tate the  need  to  schedule  SSA  user  service  capability  Tug  systems 
must  have  the  capability  to  interface  with  both  the  MA  and  SSA  or  the 
SSA  only.  TDRS  user  interface  documentation  indicates  that  an  MA 

user  can  be  supported  by  the  SSA  system.  Data  rates  would  be  restricted 
to  a maximum  of  300  Kbps  in  this  case 


8 3.2  Geosynchronous  Delivery  Mission 

The  geosynchronous  delivery  mission  was  analyzed  for  a mission  time  of  2 39 
days  The  ascent  burn  delivered  the  vehicle  to  an  altitude  of  19,323  nautical 
miles  where  a circularization  burn  placed  the  vehicle  in  a stationary  geo- 
synchronous position  at  -71  degrees  longitude  The  retro  burn  returned  the 
Tug  to  an  altitude  of  170  nautical  miles  where  a circularization  burn  placed 
the  vehicle  into  a circular  orbit.  The  mission  coverage  indicated  is  from 
TDRS-E,  TDRS-W  and  the  three  station  ground  network  composed  of  Goldstone, 
Madrid,  and  Orroral.  As  with  the  sun  synchronous  mission,  MIL,  ROS,  and  ULA 
provided  minimum  additional  coverage 

Figure  8 3 2-1  is  a timeline  of  the  geosynchronous  delivery  mission  and 
summarizes  the  orbital  support  of  both  subnets  depicted  in  Figures  8.3  2-2 
and  8.3  2-3  The  following  conclusions  can  be  drawn  from  the  timelines  and 
the  known  network  capabilities  discussed  previously  in  this  section 
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Figure  8.3.1 -1.  Tug  Sun  Synchronous  Mission  Timeline  (3  Station  STDN  and  TDRS) 
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Figure  8.3. 1-2.  Tug  Sun  Synchronous  - TDRS  Only  Case 
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Figure  8.3. 1-3.  Tug  Sun  Synchronous  - ST  ON  Only  Case 
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Figure  8.32-1.  Tug  Geosynchronous  Delivery  Mission  Timeline  (TDRS/STDN) 
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Figure  8.3.2-2.  Tug  Geosynchronous  - TORS  Only  Case 
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Figure  8.3.2-3.  Tug  Geosynchronous  • STDN  Only  Case 


• The  STDN  subnet  can  provide  support  to  all  major  burn  periods;  how- 
ever, during  low  altitude  rendezvous  with  the  Orbiter,  support  is 

1 i mi  ted. 

• Because  of  the  altitudes  involved,  the  TDRS  cannot  support  the 
retro  burn  for  return.  The  TDRS  can  support  the  rendezvous  phase 
with  the  Orbiter. 

• The  geosynchronous  mission  will  require  the  coordinated  support 
of  the  STDN  and  TDRS  subnets. 

t If  the  Tug  outputs  data  at  a 64  Kbps  rate  or  256  Kbps  rate  during 
burn  periods,  the  MA  system  will  not  sufficiently  support  the  Tug 
and  other  users.  This  may  necessitate  the  need  for  the  SSA  user 
service  capability.  Tug  systems  may  have  to  have  the  capability 
to  interface  with  both  the  MA  and  the  SSA  user  systems. 

8.3.3  Interplanetary  Mission 

The  interplanetary  mission  analyzed  was  1.27  days  in  length.  The  ascent  burn 
delivers  the  kick  stage/payload  to  an  altitude  of  737  nautical  miles  at  22 
degrees  latitude  and  155  degrees  longitude  where  separation  occurs.  The  ascent 
burn  sent  the  Tug  into  a high  elliptical  orbit  with  an  apogee  of  approximately 
30,000  nautical  miles.  The  mission  coverage  indicated  is  from  TDRS-E,  TDRS-W 
and  the  three  station  ground  network  composed  of  Goldstone,  Orroral , and 
Madrid. 

Figure  8. 3. 3-1  is  a timeline  of  the  interplanetary  mission  and  summarizes  the 
orbital  support  provided  by  the  STDN  and  TDRS  subnets.  Individual  subnet 
support  is  projected  in  Figure  8. 3. 3-2  and  Figure  8. 3. 3-3.  The  following 
conclusions  can  be  drawn  from  the  timelines,  known  network  capabilities,  and 
the  onboard  systems  capabilities. 

• Support  provided  by  the  STDN  is  limited  to  the  hyperbolic  burn. 

• The  TDRS  can  provide  support  only  to  the  hyperbolic,  and  retro  burns, 
since  the  ascent  and  circularization  burns  occur  in  the  zone  of 
exclusion  for  the  mission  analyzed. 

• The  STDN  does  not  enhance  network  support  for  the  Tug. 

• If  the  Tug  outputs  data  at  64  Kbps  rates  or  higher  during  burn 
periods  and  onboard  recorder  dump  periods,  the  MA  system  will  not 
sufficiently  support  the  Tug  and  other  users.  This  will  necessitate 
the  need  to  schedule  SSA  user  service  capability.  The  onboard  system 
must  have  the  capability  to  interface  with  both  the  MA  and  SSA  user 
systems . 

8.3.4  Summary  of  Communications  Support 

The  STDN  ground  sites  will  have  the  capability  to  support  the  16  Kbps,  64  Kbps 
and  256  Kbps  data  rates  from  the  Tug.  However,  the  NASCOM  capability  from 
the  STDN  ground  station  to  the  Tug  operations  centers  have  not  been  specified. 
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Figure  8.33-1.  Tug  Interplanetary  Mission  Timeline  (TDRS/STDN) 
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Future  8 3 3-2  Tua  Interplanetary  - STDN  Only  Case 
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Figure 8 3 3-3  Tug  Interplanetary  - TO  US  Only  Case 


Based  on  today’s  standards*  16  Kbps  is  possible  in  real  time,  but  the  64  Kbps 
could  not  be  supported  without  modification  to  the  rate. 

The  TDRSS  user  support  requirements  will  be  varied.  For  instance,  the  Tug  16 
Kbps  requirement  can  be  met  by  the  Multiple  access  system  However,  a 64  Kbps 
requirement  during  burn  periods  may  preclude  the  use  of  the  MA  system  by  the 
Tug,  primarily  because  bandwidth  requirements  would  limit  the  use  of  the  TDRS 
MA  system  by  other  users  The  same  reasoning  applies  to  the  onboard  recorder 
dumps,  which  is  expected  to  be  at  64  or  256  Kbps  The  most  obvious  solution  is 
to  require  the  Tug  to  interface  with  the  S-band  single  access  system  during 
burns  and  onboard  recorder  dumps  At  this  time  the  MA  user  can  interface  with 
the  SSA  system  with  a minimal  hardware  impact  However,  this  should  be  pursued 
in  greater  detail  due  to  the  significance  of  the  requirement 

Mission  planners  are  advocating  the  use  of  a 256  Kbps  TM  link  during  burn  and 
post  burn  periods  The  S-band  single  access  user  services  and  the  Ru-band 
single  access  user  services  can  provide  the  required  capability  only.  This 
would  preclude  the  user  of  the  Multiple  Access  system  The  SSA  concept  is 
similar  to  the  MA  concept,  however,  the  number  of  simultaneous  users  is  limited 
as  well  as  the  means  of  the  TDRS  to  provide  support  Future  mission  planning 
activities  should  assess  the  availability  of  the  SSA  systems  for  Tug, 
realizing  that  one  TDRS  can  support  only  two  SSA  users  simultaneously. 

The  addition  of  ORR  and  GDS  add  sigificantly  to  the  high  altitude  orbital 
missions  coverage  (interplanetary  and  geosynchronous)  for  which  they  are  con- 
figured MAD  support  is  significant  only  during  the  geosynchronous  missions. 

A limited  ground  network  (STDN)  will  not  be  adequate  to  support  a broad  spectrum 
of  low  altitude  missions  These  missions  can  best  be  served  by  the  TDRS 

It  is  also  recommended  that  the  ground  support  and  RF  requirements  be  written 
to  the  next  level  of  detail.  This  will  accomplish  two  things,  (1)  impact  the 
requirements  against  the  onboard  systems  design,  and  (2)  provide  a baseline  for 
a more  indepth  support  network  analysis  Support  requirements  should  also  be 
prioritized  to  gauge  their  impact,  mandatory,  highly  desirable,  desirable,  and 
etc. 

The  study  provided  network  coverage  times  based  on  simplistic  earth-vehicle- 
TDRS  geometrical  considerations  only.  Further  studies  should  consider  other 
variables  as  mentioned  in  Section  8.2  1. 

• Keyhol es 

• Terrain 

• Handovers 

• Vehicle  attitudes 

• STDN  capabilities  (must  be  defined  first) 

• Vehicle  antenna  occulations 
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835  Representative  Network  Loading 

The  network  loading  created  on  the  STDN/TDRS  was  determined  based  on  several 
assumptions 

• If  the  ground  station  was  in  line  of  site  of  the  vehicle  it  supported 
the  mission. 

• The  Tug  mission  model  presented  in  the  Baseline  Space  Tug  Flight 
Operations  Document  is  representative  of  the  actual  missions  flown 

• The  Sun  Synchronous,  Interplanetary,  and  Geosynchronous  missions  are 
representative  of  these  missions 

The  typical  mission  model  presented  in  the  Baseline  Space  Tug  Flight  Operations 
document  gave  a total  of  thirty-one  Tug  missions  (deploy  and/or  retrieve)  to 
be  flown  in  1984  This  total  was  made  up  of  three  categories  of  missions  and 
is  represented  in  Figure  8 3 5-1 

• Geosynchronous  - 14  missions 

• Earth  orbital  - 12  missions 

• Earth  escape  - 5 missions 

The  three  missions  analyzed  to  obtain  network  loading  data  were  assumed  to 
provide  average  loading  data  for  all  other  missions  within  their  respective 
category  The  missions  analyzed  were 

• Geosynchronous  (GS)/geosynchronous 

• Sun  synchronous  (SS)/earth  orbital 

• Interplanetary  (IP)/earth  escape 

The  resulting  average  yearly  loadings  per  station  were  a total  of  the  hours 
required  per  station  for  support  of  the  three  missions  analyzed  Rosman  (ROS ) 
and  Merritt  Island  (MIL)  had  nearly  duplicate  coverage,  while  Alaska  (ULA) 
provided  minimum  coverage  The  minimum  station  network  configuration  that 
could  provide  economical  coverage  for  the  three  different  types  of  missions 
consist  of  Madrid  (MAD),  Orroral  (QRR),  Goldstone  (GDS) , TDRS-East,  and  TDRS- 
West  Additional  analysis  of  the  remaining  Tug  missions  would  be  required  to 
identify  the  optimum  network  configuration  for  Tug. 

8.4  OPERATING  MODES  OF  MISSION  CONTROL 

The  Space  Transportation  System  is  a vast  integrated  operation  within  which 
is  embedded  a facility  for  the  real-time  control  of  the  Space  Tug  operations 
Figure  8 4 0-1  illustrates  the  five  fundamental  control  centers  which  must  act 
together  to  effect  the  maximum  efficiency  of  operations. 

Each  of  the  designated  facilities  has  its  own  particular  requirements  The 
Spacecraft  Operations  Center  (SCOC)  is  responsible  for  the  monitoring,  command- 
ing and  controlling  of  the  Spacecraft  systems  which  support  the  scientific 
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Figure  840-1  Space  Transportation  Control  Center  Interfaces 


payload  and  for  maintaining  knowledge  of  the  Spacecraft  ephemeris  The  Space- 
craft Operations  Center  is  also  responsible  for  the  control,  processing  and 
analyzing  of  the  scientific  data  derived  from  the  experiments  carried  by  the 
Spacecraft  The  type  of  data  coming  into  the  Spacecraft  Operations  Center 
relates  to  the  trajectory,  a limited  amount  of  systems  performance  data  and  a 
large  quantity  of  scientific  data  The  outgoing  information  from  the  Spacecraft 
Operations  Center  consists  fundamentally  of  commands  to  the  Spacecraft  and  voice 
coordination  with  other  centers  within  the  operational  complex  A specific 
exception  is  the  providing  of  Spacecraft  ephemeris  data  to  the  Tug  Operations 
Center 

The  Space  Shuttle  Operations  Center  (SOC)  will  be  responsible  for  monitoring, 
command  and  control  of  the  Space  Shuttle  Orbiter  vehicle  and  the  attached 
payloads,  with  primary  emphasis  being  placed  upon  crew  safety  operational 
requirements.  The  information  supplied  to  the  Shuttle  Operations  Center  con- 
sists of  trajectory  measurement  data,  some  system  performance  information  and 
scientific  data  from  those  experiments  which  are  carried  onboard  the  Shuttle 
During  early  phases  of  the  flight,  the  Shuttle  Orbiter  trajectory  will  be 
utilized  to  provide  initial  phasing  for  the  Space  Tug  trajectory,  therefore,  it 
is  required  that  the  trajectonal  information  is  provided  to  the  Tug  Operations 
Center  (TOC).  During  the  retrieval  operation,  wherein  the  Space  Tug  is  being 
recovered  by  the  Shuttle,  the  inverse  Is  true.  The  Space  Tug  will  provide 
ephemeris  information  and  operations  coordination  with  the  Shuttle  Operations 
Center 

Of  the  three  control  centers,  the  Tug  Operations  Center  has  the  most  complex 
mission  to  perform.  The  Tug  Operations  Center  operation  is  equivalent  to  the 
combined  control  of  the  SIVB/ Instrument  Unit  in  the  unmanned  configuration 
Since  there  are  no  astronauts  to  assist  in  the  control  of  the  vehicle,  complete 
system  information  and  analytical  capability  must  be  maintained  on  the  ground  or 
integrated  into  the  onboard  data  management  system 

The  network,  consisting  of  the  TORS  and  the  STDN  for  NASA  missions.  Is  charged 
with  the  responsibility  of  routing  data  to  the  appropriate  control  center  in 
usable  format.  At  some  point  the  downlink  data  stream  must  be  split  apart  and 
segregated  into  scientific  data  routed  to  the  Spacecraft  Operations  Center, 
scientific  and  system  data  routed  to  the  Shuttle  operations  Center  and 
detailed  systems  data  routed  to  the  Tug  Operations  Center  The  network  must 
also  provide  tracking  information  to  all  three  centers 

8.4.1  Prelaunch  Operations 

Space  Tug  Operations  Center/Launch  Site  Interface  - The  Tug  Operations, Center 
(TOC)  maintains  a prelaunch  Interface  with  the  launch  site.  In  the  prelaunch 
period,  the  Tug  Operations  Center  will  monitor  prelaunch  systems  testing  from 
an  informational  and  backup  standpoint  In  some  tests,  such  as  command  checkout 
and  target  loads,  the  Tug  Operations  Center  will  play  an  active  role  The 
control  center  will  not  act  in  other  than  an  advi story  capacity  to  the  launch 
operations  center  during  most  prelaunch  testing 

Figure  8.4  0-1  presents  the  Tug  Operations  Center/launch  site  interface  flow 
during  prelaunch  periods.  There  is  no  post-launch  interface  with  the  launch 
site 


The  primary  purpose  of  the  launch  site  is  preparation  of  the  Spacecraft,  Tug 
and  Orbiter  for  launch  operations  The  interface  with  the  Tug  Operations 
Center  can  include  any  and  all  aspects  of  systems  readiness,  verification  and 
preparation  The  launch  operations  center  will  acquire,  process  and  analyze 
prelaunch  data,  and  will  provide  that  data  either  in  real-time  or  near-real - 
time  to  the  Tug  Operations  Center  for  analysis  and  concurrence  The  countdown 
will  be  conducted  at  the  launch  site 

Prelaunch  Tug  Operations  Center/Shuttle  Orbiter  Operations  Center  Interface  - 
The  Tug  Operations  Center  (TOC)  will  interface  with  the  Shuttle  Operations Center 
(SOC)  during  prelaunch  for  systems  coordination  purposes  The  Tug  requires  all 
systems  be  monitored  at  the  TOC  There  will  be  minimum  dependence  upon  the 
Orbiter  crew  for  any  functions  other  than  caution  and  warning  monitoring  No 
prelaunch  tests  of  system  performance  will  be  conducted  by  the  Orbiter  crew 
Since  the  Orbiter  crew  will  be  in  contact  only  with  the  SOC,  any  system  functions 
of  the  Tug  which  change  the  status  of  any  parameter  displayed  to  the  astronauts 
must  be  pre-coordmated  through  the  SOC  air-to-ground  voice  loop  There  will 
be  no  direct  voice  contract  between  the  Tug  Operations  Center  and  the  Orbiter 
crew 

Prelaunch  Tug  Operations  Center/Spacecraft  Operations  Center  Interface  - During 
prelaunch  operations,  the  focus  of  activity  is  on  the  launch  site,  Orbiter  and 
Shuttle  Operations  Center  The  Tug  Operations  Center  and  Spacecraft  Operations 
Center  perform  backup  and  monitoring  functions  only  The  Spacecraft  Operations 
Center  is  primarily  concerned  with  Spacecraft  readiness,  while  the  Tug  Operations 
Center  performs  the  same  assessment 

There  are  some  potential  Spacecraft/Tug  physical  interfaces  which  require 
operations  coordination  to  ascertain  the  system  operability 

Prelaunch  TQC/Network  Interface  - The  network  will  acquire  real-time  telemetry 
and  provide  a command  interface  during  prelaunch  operations  through  a ground 
site  located  near  the  launch  operations  center. 

The  Tug  Operations  Center  will  generate  commands  through  the  network  to  the 
Tug,  and  will  monitor  feedback  from  the  Tug  over  the  RF  links 

All  operational  interfaces  between  the  Tug  Operations  Center  and  network  will 
be  verified  during  the  prelaunch  phase. 

8.42  Predeployment  Operations 

Tug/Shuttle  Operations  Center  Predepl o.vinent  Interface  - The  Tug  Operations 
Center  monitors  all  downlink  data  from  the  Tug,  and  acts  as  back-up  analysis 
to  support  Orbiter-denved  Tug  concerns.  Any  communication  with  the  Orbiter 
crew  will  be  through  the  Tug  Operations  Center/Shuttle  Operations  Center 
coordination  loop.  There  will  be  no  direct  astronaut/Tgg  Operations  Center 
communication  Figure  8.4  0-1  presents  the  Tug  Operations  Center/Shuttle  Opera- 
tions Center  predeployment  interface 
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The  Shuttle  Operations  Center  functions  are  devoted  primarily  to  the  control 
and  monitoring  of  the  Orbiter  vehicle,  with  some  effort  being  devoted  to  the 
Spacecraft  and  Space  Tug  Caution  and "Warning  functions 

Primarily  the  Shuttle  Operations  Center  will  monitor  the  Orbiter  launch, 
provide  voice  communication  with  the  crew  and  real-time  data  analysis  during 
the  boost  phases. 

Following  insertion  into  low  earth  orbit,  the  Shuttle  Operations  Center  will 
be  responsible  for  managing  the  Orbiter  trajectory,  not  only  during  the  time 
period  for  shaping  the  Space  Tug  phasing,  but  also  during  the  subsequent  phases 
of  the  mission  during  which  Shuttle  onboard  particular  experiments  are  being 
conducted. 

During  all  phases,  the  Orbiter  system  will  be  monitored  for  proper  performance 
and  voice  communication  established  with  the  crew  for  the  purpose  of  coordina- 
ting system  condition  information. 

The  Shuttle  Operations  Center  will  be  deeply  involved  in  alternate  missions 
and  contingency  operations  and  support,  including  recovery,  landing  and  rescue 
operations. 

Primary  responsibilities  will  center  around  crew  safety  involvements  of  the 
Space  Transportation  System. 

TOC/SCOC  Predeployment  Interface  - At  this  time,  the  Tug  and  the  Spacecraft 
are  still  secured  within  the  Shuttle  Orbiter  cargo  bay  There  is  no signifi- 
cant difference  in  the  operations  in  the  prelaunch  and .predeployment'ipeHods 
regarding  the  interface  between  the  Spacecraft  Operations  Center  and  the  Tug 
Operations  Center  Operations  coordination  is  required  in  order  to  advise  the 
Centers  of  on-board  events  which  may  change  the  status  of  their  displays 

TOC/Network  Predeployment  Interface  - The  Network  provides  support  to  all 
control  center  operations.  The  network  acquires,  processes  and  distributes 
data  to  the  control  centers  The  primary  functions  of  network  data  support  are 
to  schedule  the  network  facility  to  meet  the  particular  program,  experiment, 
and  vehicle  support  requirements 

The  network  interface  with  the  Tug  has  been  verified  in  the  prelaunch  period 
The  interface  between  the  network  and  the  Tug  Operations  Center  in  the  pre- 
deployment  period  provides  the  information  to  the  Tug  Operations  Center  which 
was  provided  by  the  launch  site  in  the  prelaunch  period.  The  primary  function 
is  to  monitor  system  data  and  provide  backup  information  through  the  Space- 
craft Operations  Center  to  the  astronauts  in  the  event  of  operational 
coordination  requirements. 

8 4.3  Post-Pep! ovment  Operations 

The  Orbiter  crew  will  monitor  and  control  the  Tug  systems  performance  during 
all  cargo  bay  manipulator  arm  andnear-in  operations  where  there  is  a crew 
safety  involvement  After  deployment,  however,  the  operational  interfaces 
become  somewhat  more  complex 
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Figure  8 4 0-1  illustrates  the  Tug  Operations  Center/Shuttle  Orbiter  Operations 
Center  post-deploy  operations 

TOC/SQC  Post-Sep! ovment  Interface  - Data  is  provided  to  both  the  Shuttle 
Orbiter  Operations  Center  and  the  Tug  Operations  Center  and  the  Orbiter  crew 
relative  to  the  Tug  systems  condition  Any  command  action  undertaken  by  the 
Tug  Operations  Center  must  be  pre-coordinated  through  the  Shuttle  Operations 
Center  to  the  Orbiter  crew  so  that  any  change  in  system  status  indications 
will  not  be  unexpected  The  immediate  post-deploy  time  frame  is  critical  to 
mission  success  and  will  require  extreme  team  work  and  coordination  activities 
Trajectory  measurement  information  will  be  supplied  to  the  Tug  Operations 
Center  through  the  Tug  Telemetry  System  Trajectory  measurement  information 
will  be  supplied  to  the  Shuttle  Operations  Center  from  ground  based  sources 
During  the  immediate  post-deploy  period,  there  exists  an  opportunity  to  compare 
Tug  and  Shuttle  navigation  state  vector  information 

TOC/SCOC  Post-Deployment  Interface  - At  this  point  m time,  the  Spacecraft  is 
still  a passenger  aboard  the  Tug  Vehicle  System  data  from  the  Spacecraft 
will  be  provided  to  the  network  through  the  Tug  downlink  and,  in  the  network, 
will  be  distributed  to  the  Spacecraft  Operations  Center,  where  it  will  be 
assessed  and  analyzed  There  exists  the  potential  that  a command  uplink  will 
be  required  to  issue  corrective  actions  to  the  Spacecraft  systems  No  command 
action  may  be  taken  to  the  Spacecraft  without  pre-coordination  with  the  Tug 
Operations  Center  The  Tug  Operations  Center  will  be  monitoring  Tug  parameters 
and  a selected  set  of  Spacecraft  parameters 

TOC/Network  Post-Deploy  Interface  - In  the  post-deploy  operations,  the  network 
will  receive  and  process  systems  data  for  the  Tug  Operations  Center,  and  will 
provide  a command  uplink  capability  between  the  Tug  Operations  Center  and  the 
Tug  vehicle  Command  two-way  lock  is  required  during  all  mission  phases  other 
than  while  the  Tug  is  in  the  orbiter  cargo  bay  The  network  will  provide  real- 
time data  routing  and  distribution  to  all  user  agencies  The  network  will  also 
provide  a catalog  of,  and  maintain  historical  data  archieves  for,  all  programs 

8 4 4 Spacecraft  Deployment  Operations 

Figure  8 4 0-1  illustrates  the  Spacecraft  deploy  operations  coordination  loops 
The  Tug  mission  will  have  carried  the  Spacecraft  to  the  planned  deployment 
location  Since  there  exists  no  capability  for  communicating  with  the  Space- 
craft after  separation,  the  only  Tug  function  is  to  provide  a stable  attitude 
and  establish  pre-deployment  conditions  for  the  Spacecraft  prior  to  totally 
losing  contact  with  it 

The  Spacecraft  systems  will  be  activated  by  the  Tug  either  automatically  or 
through  ground  command  prior  to  separation  Upon  activation,  the  Spacecraft 
will  begin  communicating  trajectory,  system  data,  and  scientific  data  to  the 
Spacecraft  Operations  Center  The  Spacecraft  will  also  be  prepared  to  accept 
command  uplink  data  through  the  network,  if  that  capability  has  not  existed 
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previously  during  its  role  as  passenger  on  the  Tug  The  primary  coordination 
problem  is  in  ascertaining  that  the  correct  predeployment  conditions  have 
been  reached  by  the  Tug  This  requires  operations  coordination  between  the 
Spacecraft  Operations  Center  and  the  Tug  Operations  Center,  particularly  in 
the  comparison  of  ephemens  achieved  versus  ephemens  desired.  The  Spacecraft 
will  be  visually  inspected  by  the  Tug  T.V  System 

Once  separated,  the  Tug  will  phase  away  from  the  deployed  Spacecraft.  Following 
a successful  phasing  maneuver,  the  Tug  will  retro-fire  and  establish  a phasing 
orbit  preliminary  to  meeting  the  Shuttle  for  recovery 

8 4 5 Spacecraft  Docking/Retrieval  Operations 

Some  missions  will  require  the  Space  Tug  to  rendezvous  with  and  establish  a 
mechanical  lock  with  an  orbiting  Spacecraft  The  rendezvous  may  be  accom- 
plished by  using  established  phasing  and  co-elliptic  techniques.  The  unproven 
aspect  of  the  mission  is  m the  terminal  rendezvous  and  docking  components 

Figure  8 4 0-1  illustrates  the  coordination  loops  between  the  operations  support 
elements  which  are  active  during  terminal  rendezvous  and  docking 

It  is  within  the  capability  of  existing  technology  to  dock  in  a completely 
unaided  manner.  However,  there  is  a natural  reluctance  to  completely  turn 
over  docking  to  hardware  There  will  be  television  (slow  scan)  provisions 
on  the  Space  Tug  vehicle  which  will  permit  ground  monitoring  of  the  docking 

The  Space  Tug  is  the  active  vehicle  in  the  rendezvous  and  docking  sequence 
During  the  docking  and  retrieval  operations,  the  Spacecraft  Operations  Center 
will  provide  engineering  surveillance  to  monitor  Spacecraft  systems  and  provide 
command  support  as  required 

8.4.6  Space  Tug  Retrieval  Operations 

Figure  8 4 0-1  illustrates  the  coordination  loops  active  during  Space  Tug 
recovery  by  the  Space  Shuttle. 

The  Space  Tug  Operations  Center  will  receive  an  ephemens  of  the  Shuttle 
Orbiter,  or,  equivalently,  target  pre-settings,  from  the  Orbiter  Control 
Center  prior  to  beginning  the  final  retrieval  sequence 

The  Space  Tug  will  compute  the  optimum  maneuver  sequence  to  meet  the  Orbiter 
with  the  targeted  differential  height  and  phase  relationship.  This  computa- 
tion will  be  verified  by  ground  sources  at  the  TOC,  and  altered  by  uplink 
command  if  significant  variance  is  detected.  Normally,  the  Space  Tug  will 
maneuver  to  the  targeted  orbit  without  ground  intervention. 

Having  achieved  the  waiting  orbit,  the  Space  Tug  systems  will  be  deactivated. 
Ground  monitoring  will  verify  deactivation  The  Space  Tug  will  be  the  dormant 
vehicle  during  recovery  When  the  Shuttle  Orbiter  is  within  20  miles  range, 
communication  can  be  established  with  the  Tug.  The  operation  then  becomes 


the  primary  responsibility  of  the  Qrbiter  crew  and  the  SOC  The  Tug  Operations 
Center  continues  to  monitor  the  Space  Tug  through  the  recovery  operation  and 
to  advise  the  SOC  as  necessary 

When  the  recovery  operations  are  over  and  the  Tug  (with  or  without  Spacecraft) 
has  been  secured  in  the  orbiter  cargo  bay,  the  Tug  will  be  inactive  through 
landing  The  TOC  monitoring  function  will  cease  when  Tug  telemetry  1S  no  lonqer 
available 

847  Landing  Operations 

No  operational  requirements  have  been  identified  that  apply  during  the  landing 
phase 

8 5 CONSIDERATIONS  FOR  "NEW  BUILD"  CONTROL  CENTER  DESIGN 

The  objective  of  this  task  was  to  identify  development  concerns  incurred  during 
the  establishment  of  NASA/DoD  Mission  Control  Centers  All  elements  of  the 
Mission  Control  Center  development  activity  were  addressed,  with  existing 
approaches  identified,  so  that  developmental  problems  could  be  avoided  m 
defining  the  IUS/Tug  operations  concepts,  functions,  and  plans  Several 
center/programs  were  assessed  for  requirements,  such  as,  staffing,  computer 
capability,  software,  hardware  and  facility  Those  centers  included  are 
JPL-Deep  Space,  AMES-Pioneer,  JSC-Apollo  and  Gemini,  GSFC-Unmanned  Satellites 
and  the  Air  Force  Satellite  Test  Center  (AFSTC) 

851  NASA/JSC  Development  Concerns 

8511  Operational  Philosophy 

Prior  to  discussing  any  development  activities,  it  is  benefical  to  understand 
the  operational  objectives  and  environment  of  each  center  JSC  is  currently 
configured  (as  in  the  past)  to  support  missions  of  relatively  short  durations 
on  an  infrequent  launch  basis 

The  JSC  Mission  Control  Center  and  associated  tracking  stations  are  set  up 
as  a system  rather  than  project  oriented,  therefore,  it  is  reconfigured  from 
project  to  project  Occasionally  part  of  the  system  (i  e , control  console, 
displays,  memory  systems)  are  updated  or  upgraded,  however,  an  attempt  is 
made  to  normally  have  the  resources  required  to  support  a project,  rather  than 
modify  the  MCC  into  a project  specific  configuration  When  equipment  is 
acquired  to  support  a project,  a growth  factor  is  added  whenever  possible 
to  accommodate  future  requirements 

8.5  1 2 Systems  Configurations 

The  basic  MCC  consists  of  the  Real  Time  Computer  Complex  (RTCC)  composed  of 
five  IBM  S360/75's  on  parallel  Input  and  output  busses,  console  areas  for 
flight  controllers,  network  controllers  (STDN),  and  instrumentation  controllers 
Real  time  processing  is  a major  MCC  effort  The  second  largest  effort  is 
system  validation  and  training  The  RTCC  is  used-  99  percent  of  the  time  in 
these  roles,  with  one  percent  of  the  total  utilization  spent  on  actual  flight 
support  The  third  largest  effort  is  the  off-line  data  processing  by  other 
computers,  Umvac  1108,  however,  the  RTCC  computers  provide  the  interface  for 
this  data  as  input  to  JSC  from  the  remote  sites 
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To  alleviate  scheduling  problems,  NASA  writes  a development  plan  for  each 
major  MCC  change  This  plan  assures  a close  coordination  of  the  contractors 
and  government  and  is  closely  followed  and  reviewed  to  identify  problems  at 
an  early  stage  A need  was  developed  for  extensive  software  configuration 
planning  and  development  control. 

Some  development  concerns  were  created  outside  the  realm  of  the  MCC,  however, 
a direct  relationship  exists  from  data  acquisition  by  the  onboard  sensor  to 
data  processing  at  the  MCC.  This  resulted  in  a major  problem  in  ground  tele- 
metry processing  caused  by  the  non-uniformity  of  onboard  data  communication 
systems.  An  indexing  counter  m the  mam  frame  would  simplify  the  ground 
decommutation  process  in  many  cases,  however,  it  was  not  provided  because  it 
is  not  required  for  onboard  commutation.  NASA  should  coordinate  the  commutation 
and  decommutation  developments  to  reduce  the  total  cost  of  data  processing 

8.5.1  3 Roles  and  Responsibilities 

There  are  about  160  NASA  people  and  900  contractor  personnel  active  m the  JSC 
MCC  operation.  IBM  is  the  software  contractor  and  integrator  for  the  RTCC, 
and  Phil co  Houston  Operation  (PHQ)  is  the  hardware  integrator  and  system 
Maintenance  and  Operations  contractor  for  all  except  the  RTCC.  Various  manu- 
facturers provide  contracted  maintenance  on  their  data  processing  equipment 
NASA  retains  the  system  integrator  and  system  engineer  roles,  and  additionally 
supplies  facilities  and  precision  measurements  and  equipment  laboratories 

8 5.1  4 Identified  Design/Development  Concerns 

Further  evidence  of  the  end  to  end  impact  of  processing  on  the  data  flow 
system  occurred  during  the  Gemini  mission.  It  was  found  that  the  command 
uplink  had  been  designed  to  give  a very  low  error  rate  (redundant  commands, 
encoding,  high  gain  antennas,  etc  ) while  command  verification  was  based 
on  a two  watt  transmitter  in  a high  error  rate  link.  The  result  was  that 
errors  in  the  downlink  caused  the  MCC  to  transmit  many  commands  unnecessarily 

JSC  committed  early  in  the  development  stage  to  reconfigure  the  RTCC  by 
software  changes  when  signal  sources  varied  between  missions.  In  some 
instances,  where  there  was  a minimum  time  between  launch  centers  and  signi- 
ficant requirement  for  support,  simulation,  or  training,  software  changes  were 
not  possible  and  wiring  changes  proved  more  feasible.  Software  freezes  caused 
subsequent  reconfigurations  to  be  made  by  rewiring  the  data  inputs  to  the 
RTCC's.  Wiring  changes  were  selected  because  of  simpler  validation  and  less 
man  hours 

The  MCC/User  interface  needs  attention  to  assure  that  anomalies  in  the 
experiment  are  understood  by  the  personnel  creating  the  telemetry  reduction 
software  In  essence,  the  software  was  designed  to  operate  with  less  than 
perfect  data.  Rather  than  requiring  simple  software  changes,  such  as  change 
coefficients,  software  required  more  extensive  programming  efforts,  revalu- 
ation, etc.  If  software  were  more  flexible,  the  software  quality  assurance 
effort  could  then  identify  immediate  products  in  the  processing  needed  to 
assure  that  discrete  steps  are  properly  implemented.  In  many  other  cases, 
the  user  stated  his  requirements  without  considering  the  processing  load 
involved  (color  imagery  vs  black  and  white),  which  resulted  in  a reduced 
utilization  of  the  MCC  resources. 
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852  NASA/JPL  Development  Concerns 

8521  Operational  Philosophy 

The  JPL  Mission  Command  and  Control  Center  (MCCC)  is  viewed  as  a support 
service  to  the  various  deep  probe  programs  offices  “Institutional  Software" 
at  JPL  performs  the  actual  communications  functions  with  the  Deep  Space 
Network  (DSN)  sites  in  Spain,  Australia  and  Goldstone,  California  Other 
"institutional"  routines  for  orbit  planning,  video  and  telemetry  reduction, 
and  command  generation,  are  available  for  use  by  the  probe  program  Mariner 
(JPL)  is  controlled  in  the  JPL  Mission  Test  Control  Facility  (MTCF,  Umvac 
1218,  1230  and  116  computers)  Pioneer  is  controlled  at  NASA  Ames  (Xerox 
Sigma  5s  and  PDP  11s)  Viking  (NASA  Langley)  will  be  controlled  at  JPL, 
and  Helios  at  Munich,  Geormany  As  a result  JPL  builds  some  spacecraft,  e g , 
Mariner,  and  functions  as  the  data  gathering  and  communications  center  for  the 
probe  controllers,  wherever  they  are  located  It  also  provides  institutional 
software  and  computer  resources  to  the  requesting  Project  Offices,  but 
spacecraft  control  resides  with  the  builder,  not  the  DSN 

8522  System  Configuration 

The  MCCC  consists  of  three  computer  complexes,  the  Mission  Computing  Center 
Facility,  (MCCF,  three  IBM  360/75),  the  General  Purpose  Control  Facility 
(GPCF,  a Umvac  1108),  and  the  MTCF  used  for  Mariner  The  DSN  has  210  foot 
and  85  foot  dishes  at  each  of  three  locations,  with  high  (117  Kbps),  medium 
(51  2 and  22  05  Kbps),  and  low  (2  4 and  4 8 Kbps)  rate  data  lines  connected 
to  an  IBM  360/75  in  the  MCCF  During  operations,  two  360/75s  share  the  data 
lines  and  computing,  although  only  one  set  of  outputs  is  used  (hot  switching 
to  backup  is  possible)  The  MCCF  handles  command  bit  structure  generation  and 
data  packing/unpacking  in  real  time,  with  up  to  six  data  lines  simultaneously 
The  unpacked  telemetry  may  be  routed  to  the  GPCF,  MTCF  or  other  operations 
control  centers  The  1108  computer  performs  orbital  planning  and  control, 
while  the  360s  are  primarily  real  time  processing  machines,  with  resident 
software  freezes  before  operational  contacts  to  assure  software  integrity. 

The  long  time-line  in  JPL  missions  allows  development  of  operational  software 
after  spacecraft  launch,  so  that  360  software  development,  testing  and  vali- 
dation is  a continuous  process  at  the  MCCF,  generally  on  the  third  (offline) 
machine  Attached  to  the  DSN  before  the  data  enters  the  MCCF  is  a network 
control  computer,  which  continuously  monitors  data  quality  and  constructs  a 
Master  Data  Record,  to  duplicate  the  Original  Data  Record  at  the  site 

8 5 2.3  Roles  and  Responsibilities 

Jet  Propulsion  Labs  of  California  Institute  of  Technology  is  a NASA  contractor, 
and  other  NASA,  government  and  JPL  contractors  reside  at  JPL  Phil  co-Ford 
is  the  JPL  subcontractor  operating  m the  data  services  division  for  manning 
and  operating  the  Goldstone  Complex  with  1000  people  The  4000  total  JPL 
employment  includes  spacecraft  designers,  builders  and  system  engineers  for 
the  DSN  The  role  of  JPL  is  different  from  probe  to  probe,  as  is  the  util- 
ization of  the  JPL/DSN  resources.  The  different  probe  efforts  utilize  the 
MCCF  and  JPL  data  services  to  different  extents,  depending  on  the  size  and 
talents  of  the  probe  program  office  and  their  support  contractors  As  an 
example.  Pioneer  6 through  9 installed  telemetry  processors  at  the  DSN  sites 
to  reduce  telemetry  and  transmit  it  via  TTY  to  NASA  Ames,  where  analysts 
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could  telephone  the  MCCF  to  have  commands  transmitted  For  Pioneers  10  and 
11,  the  telephone  has  been  replaced  by  a data  link  from  the  Ames  Sigma  5 
through  its  PDP  11  to  the  JPL  360/75.  This  link  also  carries  the  Pioneer 
telemetry.  The  DSN  sites  operate  as  a "bent  pipe"  and  no  longer  perform 
telemetry  reduction 

8.5  2 4 Identified  Design/Development  Concerns 

The  software  freeze  on  the  360/75  for  an  operation  impacts  software  development/ 
testing  for  the  programs  The  Support  Instrumentation  Requirements  Document 
(SIRD),  which  levies  support  requirements  on  JPL  and  the  DSN,  should  be 
expanded  to  show  expected  freezes  in  the  timeline  of  each  probe's  associated 
software  development  cycle  JPL  allocates  resources  by  committing  themselves 
to  the  SIRD  requirements 

Software  testing  has  expanded  from  five  men  to  30  to  reflect  the  intricate 
software  relations  in  the  360/75  computers  and  to  give  more  confidence  in 
software  development 

Scheduling  is  accomplished  by  resource  - DSN,  MCCF,  GPCF  and  MTCF,  so  that 
a space  probe  office  must  schedule  each  resource  weekly,  rather  than  put  the 
input  into  a network  scheduling  office  which  would  combine  all  requests  for 
all  resources  High  priorities  are  allocated  to  operations  and  state  of 
health  problems,  so  that  the  remaining  operational  problems  are  of  a low  level 
nature,  but  can  impact  software  development 

8.5.3  Pioneer  Mission  Operations  Control  Center  Development  Concerns 
8 5.3  1 Operational  Philosophy 

The  Pioneer  Mission  Operations  Control  Center  (PM0CC)  capabilities  have  been 
developed  to  control  two  Spacecraft  CSC),  Pioneers  10  and  11.  Because  the 
Pioneers  are  nearly  fly-by-wire,  most  changes  in  the  SC  are  commanded  from 
the  ground.  Only  a few  emergency  shutdowns  are  accomplished  automatically 
by  the  SC  This  imposes  real-time  state  of  health  monitoring  of  every  SC 
subsystem  on  the  MCC.  To  meet  this  requirement,  pre-programmed  command 
sequences  to  shut  down  a subsystem  are  stored  at  the  MCC  and  at  each  Deep 
Space  Network  CDSN)  station.  Extensive  DSN  loss  of  communications  procedures 
are  necessary  to  preserve  the  SC  m the  event  of  MCC-DSN  communication  outages 
With  a one  way  RF  delay  of  50-60  minutes,  there  is  time  for  the  MCC  to  call 
SC  subsystem  specialists  in  to  help  on  equipment  problems  while  pre-programmed 
commands  are  being  set  The  large  round  trip  delay  and  fly-by-wire  nature  of 
the  SC  have  caused  the  MCC  to  be  designed  around  real  time  state  of  health 
checks  and  having/updating  elaborate  contingency  command  plans  to  "safe"  the 
SC  until  a subsystem  specialist  can  perform  detailed  evaluation  of  the  sub- 
system "Quick  look"  telemetry  reduction  is  performed  in  the  MCC  for 
functional  command  verification  This  includes  gam  changes,  telemetry  mode 
changes,  attitude  and  control  system  configuration  changes,  etc. 

The  MCC  was  designed  from  the  start  (it  is  a converted  conference  room)  for 
the  Pioneer  Mission,  and  for  budgetary  reasons  maximum  use  of  prelaunch 
ground  test  computers  for  flight  support  is  a driving  concept.  The  same  office 
that  operates  the  PM0CC  also  acquired  the  spacecraft,  therefore,  the  systems 
contractors  were  responsive  to  developing  the  ground  test  fixtures  for  their 
dual  roles 
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8532  System  Configuration 

The  PMOCC  has  three  Xerox  Sigma  5 computers,  two  of  which  were  used  for  Space- 
craft checkout,  and  two  PDP  II  communications  concentrators  A Sigma  5 and 
PDP  II  are  dedicated  to  each  Pioneer,  with  the  third  Sigma  5 performing 
offline  processing,  with  the  capability  to  be  switched  to  online  real-time 
support  The  system  has  evolved  from  heavy  reliance  on  JPL  360/75  computers 
for  DSN  site  support  to  performing  all  real  time  functions  in  the  PMOCC,  with 
JPL  providing  metric  orbit  reduction  and  calculations  for  course  changes  This 
change  was  made  to  reduce  the  effects  of  software  freezes  on  the  JPL  360/75 
caused  by  a critical  phase  of  any  of  the  Spacecraft  sharing  the  DSN  The  JPL 
360/75  has  resident  routines  supporting  each  of  the  Spacecraft,  and  it  has 
been  necessary  at  times  to  freeze  all  software  development  in  order  to  pre- 
vent changes  on  the  program's  software  from  disrupting  the  computer  during  a 
critical  portion  of  another  program's  flight  Moving  this  application  soft- 
ware to  the  PDP  II  and  Sigma  5 has  minimized  the  impact  of  these  freezes  on 
PMOCC  software  development  The  real  time  support  positions  are  a controller 
for  each  Pioneer  and  a technical  assistant  for  both  These  personnel  command, 
read  telemetry,  and  assure  state  of  health  of  the  SC  Offline  processing  of 
Master  Data  Records  for  the  DSN  sites  is  performed  around  the  clock  Experi- 
menters and  subsystem  specialists  are  on  call,  and  perform  other  functions 
while  the  Spacecraft  are  in  the  cruise  mode  The  manning  jumps  during  contact 
periods,  and  the  offline  processing  changes  to  provide  "quick  looks'  at  sub- 
system data  The  intent  in  the  PMOCC  design  is  to  provide  the  minimum  resources 
necessary  to  do  the  job,  with  a large  cross-pollemzation  among  the  center 
personnel 

8533  Roles  and  Responsibilities 

The  Pioneer  mission  is  a typical  case  where  the  Space  Project  Office  (SPO) 
procures  both  the  spacecraft  and  the  ground  data  processing  system,  with  JPL 
and  the  DSN  providing  the  data  collection  resources  Present  NASA  mission 
operations  personnel  number  20,  with  52  Bendix  support  people  in  four  groups 
Flight  Operations,  Data,  Mission  Analysis,  and  Launch  Operations.  Flight 
Operations  are  the  controllers  and  technical  assistants,  performing  SC 
control,  real  time  telemetry  readout  of  the  science  and  SC  equipments,  and 
real  time  interfacing  with  JPL  and  the  DSN  The  Data  group  operates  the 
computers,  and  accomplishes  hardware  and  software  development  to  support 
the  mission  The  Mission  Analysis  and  Launch  Operation  groups  have  various 
roles  that  change  with  the  mission  phase  Both  NASA  and  Bendix  are  flexible 
in  the  roles  that  the  offline  personnel  perform  as  the  mission  progresses 
The  software  is  unique  to  PMOCC,  and  has  been  developed  by  the  SPO,  including 
the  launch  support  software  The  hardware  has  been  salvaged,  rented  and  con- 
tracted for,  with  manufacturer  maintenance  wherever  possible  The  maintenance 
contractor  performs  all  modifications  to  his  equipment.  Bendix  performs 
system  maintenance  mods,  interconnects,  etc  , to  the  equipment  otherwise 
unsupported  These  include  the  consoles,  bit  syncs,  and  telemetry  station 

JPL's  role  is  that  of  data  gatherer  and  DSN  interface,  and  also  provides  the 
use  of  high  cost  resources,  such  as  the  orbit  determination  and  some  image 
processing  equipment 

The  trend  has  been  to  concentrate  the  real  time  functions  at  PMOCC,  minimizing 
dependence  on  the  JPL  computers  for  DSN  support  A major  problem  is  DSN 
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resource  allocation,  with  several  programs  requesting  maximum  data  receipt, 
and  the  many  programs  competing  for  the  same  resources  Weekly  scheduling 
meetings  handle  normal  conflicts,  with  real  time  changes  when  a Spacecraft's 
health  is  threatened.  This  forces  the  Pioneer  Mission  Office  to  gather  weekly 
requests  from  the  scientists  as  inputs  to  the  scheduling  process.  There  is  a 
DSN  operations  control  center  at  JPL  in  voice  contact  with  the  stations,  but 
normally  PMQCC  is  in  voice  contact  with  JPL,  and  not  the  sites 

8. 5.3.4  Identified  Design/Development  Concerns 

Resource  allocation  at  JPL  has  caused  PMQCC  to  become  self-reliant  wherever 
possible  Although  duplicating  existing  capabilities,  by  having  them  at 
PMOCC,  the  SPO  has  gained  development  resources  that  would  normally  be 
shared  if  at  JPL. 

The  flexibility  of  the  NASA  staff  is  a response  to  the  shifting  workload  in 
PMOCC  and  is  an  effort  to  broaden  in-house  capabilities 

8.5.4  NASA/GSFC  Development  Concerns 
8 5 4.1  Operational  Philosophy 

NASA  GSFC  has  been  developed  to  support  satellite  payloads.  Current  design 
objectives  are  to  standardize  the  Multi satellite  Control  Center  (MCC),  and 
to  automate  configuration  changes  from  one  satellite  pass  to  the  next. 

Another  goal  is  to  have  standardized  software  and  operator  interfaces  so 
that  modular  improvements  can  be  made.  The  prime  mission  of  the  MCC  is  the 
health  and  safety  of  the  SC,  with  other  Goddard  divisions  handling  software, 
data  analysis,  orbit  reduction,  and  data  reduction. 

8 5 4.2  System  Configuration 

The  MCC  is  built  around  a digital  switch,  SCADI,  which  is  really  three  PDP 
ll-20s;  These  provide  connections  between  the  computers  [XEROS  930s  and 
Sigma  5s),  PCM  converter  decoders,  strip  chart  decoders,  CRTs  and  consoles, 
and  the  data  lines  from  the  sites  Up  to  10  simultaneous  satellite  supports 
are  possible  In  the  past,  each  console  and  computer  group  was  custom  built 
for  a particular  satellite,  but  the  movement  to  grouping  common  functions  and 
providing  standard  consoles  is  underway.  The  three  SCADI  computers  function 
as  executive,  online  and  backup,  with  real  time  switching  possible  Simple 
format  conversions  are  also  performed  in  the  SCADI,  with  an  emphasis  on 
automatic  reconfiguration  of  the  system  as  the  support  load  changes.  The 
SCADI  also  monitors  the  data  blocks  from  site  and  performs  real  time 
corrections  and  diagnostics  on  the  data 

8.5.4  3 Roles  and  Responsibilities 

RCA  is  the  Maintenance  and  Operations  contractor  at  the  MCC,  in  a ratio  of 
seven  RCA  to  each  NASA  person  in  flight  operations.  The  NASA  MCC  design 
staff  numbers  15.  Goddard  requires  standard  interfaces  from  the  SC  builder, 
with  a Support  Instrumentation  Requirements  Document  detailing  the  agreement. 
This  formal  document  is  regularly  reviewed  and  is  the  vehicle  for  handling 
conflicts  between  SC  builder  desires  and  ground  capabilities.  The  level  of 
normal  support  is  herein  defined,  and  requests  for  more  than  this  must  be 
approved  by  higher  NASA  offices. 
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Wherever  possible  the  SC  contractor  is  asked  to  develop  test  software  on 
compatible  machines,  in  a structure  so  that  it  can  later  be  used  in  flight 
operations  Structurally,  NASA  designates  a member  of  the  MCC  project  staff 
as  user  interface,  where  the  definition  of  ground  system  processing  of  SC 
data  is  performed  in  real  time  This  man  is  also  the  responsible  person  for 
MCC  operations  in  support  of  the  SC  To  assure  hardware/software  compatibility, 
the  Control  Center  Systems  Managers  have  complimentary  backgrounds,  and  both 
must  initial  design  reviews  of  all  hardware  and  software  developed  for  the 
MCC  No  new  software  development  is  allowed  until  the  specifications  for 
the  changes  are  approved,  and  the  interfaces  defined 

8 5 4 4 Identified  Design/Development  Concerns 

The  GSFC  MCC  has  become  conservative  in  technology  utilization,  reflecting  a 
small  budget 

A Digital  Data  Processing  System,  a minicomputer  with  large  disk  storage, 
is  being  procured  to  allow  post  pass  playback  of  the  entire  pass  over  low 
quality  voice  lines.  This  system  will  eliminate  the  shipping  of  range 
tapes  in  most  cases 

Unplanned  MCC  processing  changes  are  handled  with  software  changes  wherever 
possible,  reflecting  the  shorter  development  cycle  of  minor  program  changes 

The  MCC  design  is  frozen  about  3 to  4 months  before  launch  to  allow  30-45 
days  for  operator  training  and  another  30-60  days  for  simulation  and  rehearsals 
This  early  freeze  has  become  necessary  to  confidently  assess  MCC  readiness 
Changes  are  allowed  only  at  times  agreed  to  by  the  M&Q  and  NASA  staffs  This 
freeze  provides  a system  baseline  early  enough  to  make  the  necessary  changes 

Two  basic  questions  in  MCC  development  are  "What  are  the  real  requirements?" 
and  "When  is  it  really  ready?"  The  designated  member  of  the  project  staff 
to  interface  with  the  user,  and  the  MCC  design  freeze  are  the  GSFC  responses 
to  these  questions,  along  with  the  regular  reviews  of  the  Support  Instrumentation 
Requirements  Document 

855  DoD/SGLS  Development  Concerns 

This  section  does  not  include  the  operational  philosophy  and  systems  descriptions 
as  previously  defined  at  the  other  centers  due  to  sensitivity  of  the  data. 
However,  a summary  of  the  concerns  is  described  below  in  general  terms 

Identified  Design/Development  Concerns  - Several  problem  areas  can  be 
related  to  other  centers  as  well  as  the  Satellite  Control  Facility  (SFC) 

Once  software  tradeoffs  had  been  performed  a software  freeze  was  initiated 
The  premature  freeze  impacted  developmental  program  design  as  well  as  changes, 
integration  among  contractors,  and  the  relationship  of  the  contractor  and  his 
role  in  the  facility 

The  network  does  not  have  the  resources  to  satisfy  all  support  requirements 
levied  by  users,  primarily  due  to  computer,  communications  and  tracking- 
station  limitations.  For  months  at  a time,  a Remote  Tracking  Station  (RTS) 
will  have  no  unscheduled  periods  if  it  has  the  capability  to  service  both 
polar  and  equatorial  high  energy  orbit  satellites  The  small  on-line 
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computers  have  been  so  heavily  loaded  in  recent  years  that  an  emulator  system 
having  a five-fold  increase  in  throughput  is  being  procured  Eventually  the 
existing  software  will  be  replaced  by  a new  software  system  The  number  of 
hours  spent  m real  time  support  has  increased  each  year,  and  currently  saturates 
the  computer  resources  The  wideband  data  system,  where  data  rates  to  1 024 
Mbps  are  supplied  directly  from  an  RTS  to  a Systems  Project  Office  (SPO) 
telemetry  reduction  center,  is  expected  to  offload  some  of  the  Satellite 
Test  Center  (STC)  computer  requirements 

System  rehearsals  are  not  as  extensive  as  NASA's,  because  the  missions  tend  to 
be  evolutionary,  with  evolutionary  software  changes  to  accommodate  them  The 
melding  of  contractor  telemetry  reduction  facilities  into  the  real  time  loop 
will  be  a problem  in  future  rehearsals 

In  the  Advanced  Data  System  era  (1967  - 1969),  large  scale  concurrent 
development  of  new  computers,  buffers  and  software,  caused  many  problems, 
and  an  interim  software  system  with  minimal  changes  became  the  standard 
system  (Model  A)  Since  then.  Model  A has  gradually  evolved  into  the  dual 
computer  processor  system  originally  requested  in  the  ADS  era  This  gradual 
evolution  is  now  preferred  for  meeting  new  requirements. 

85.6  New  Control  Center  Development  Approach 

The  assessment  of  the  mission  control  centers  m the  previous  paragraphs 
was  based  on  the  particular  role  of  that  center  and  the  specific  types  of 
missions  they  supported  Several  items  appear  significant  in  determining  the 
development  philosophy  for  a new  control  center 

Planning  and  close  coordination  has  been  a key  to  the  development  of  new  MCC's 
Problems  were  solved  more  easily  in  the  past  by  utilization  of  a detailed 
development  plan  and  close  coordination  and  review  with  the  developers  and 
implementators  Close  coordination  provided  early  identification  of  problem 
areas  and  allowed  flexibility  for  long  lead  time  changes 

The  development  plan  should  specify  a system  that  has  growth  potential  to 
meet  future  requirements  The  upgrading  of  a system  is  preferred  by  a 
gradual  evolutionary  process  rather  than  by  drastic  changes. 

The  MCC  should  have  the  capability  to  restructure  its  systems  on  its  own 
timeline.  Or  the  MCC  should  thoroughly  understand  the  ramifications  of 
utilizing  institutional  resources  (hardware/software)  that  may  be  in  contention 
by  other  programs.  In  the  same  vein,  the  MCC  should  not  contend  for  its  own 
resources,  i e.,  software  development  on  a machine  that  is  providing  mission 
support. 

The  MCC  development  should  be  streamlined,  deleting  redundant  operations  and 
development  cycles  For  instance,  test  software  should  be  developed  on  MCC 
compatible  machines,  such  that  the  software  can  later  be  used  in  flight 
operations 

The  MCC  should  establish  a definite  interface  with  other  facets  of  the 
data  flow,  NASCOM,  GSFC  and  the  STDN/TDRSS  subnets  The  MCC  should  realize 
a continued  increase  in  support  requirements  from  other  programs  may  negate 
those  services  once  supplied  by  NASCOM  or  GSFC  (Orbit  determination),  etc. 
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The  MCC  should  also  establish  a definite  interface  with  its  users,  defining 
the  capabilities  it  can  provide  and  the  requirements  the  user  systems  must 
meet  to  utilize  these  capabilities  This  will  prevent  the  user  from  over- 
loading MCC  systems 
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A significant  number  of  missions  m the  Space  Transportation  System  model 
set  cannot  be  achieved  by  the  Earth  Orbiting  Shuttle  Vehicle  This  is 
because  its  performance  capabilities  limit  it  to  near-earth  missions.  To 
extend  the  capabilities  of  the  System,  an  additional  stage  (Space  Tug)  has 
been  added  to  the  basic  shuttle  vehicle 

Implicit  in  the  addition  of  the  Tug  is  the  necessity  for  a ground  network 
and  control  center  for  monitoring  and/or  control  of  the  Tug  vehicle  during  its 
mission  The  complexity  and,  therefore,  the  development  costs  of  the  Tug 
Control  Center,  is  a function  of  the  requirements  resulting  from  the  mission 
profile  and  the  autonomous  capabilities  of  the  onboard  avionics  of  the  Tug 
vehicle 

Tug  vehicle  avionics  have  the  greatest  influence  on  operational  autonomy 
Onboard  autonomy  establishes  the  required  degree  of  ground  control 
and  monitoring  Allocation  of  functions,  such  as  navigation,  influence  the 
avionics  requirements  From  a mission  standpoint,  this  function  must  be 
performed,  and  if  not  accomplished  onboard,  it  must  be  done  by  the  ground. 

It  follows  that  the  more  autonomous  Tug  operation  permits  a decrease  in 
ground  operations  The  following  are  characteristics  of  the  two  autonomy 
levels 

• Level  II  Autonomy 

MSFC  Baseline  Tug 

Autonomous  Navigation  (ILT) 

Rendezvous  and  Docking  Closed  Loop  thru  On-Board  Sensors 


■ Level  III  Autonomy 

MSFC  Baseline  Tug 

Ground  Tracking  Required,  No  Autonomous  Navigation 
Rendezvous  and  Docking  Uses  Man-in-the-Loop  TV 

This  section  presents  the  baseline  operations  plan  for  a Space  Tug  vehicle 
designed  for  operation  at  Level  II  autonomy.  The  Baseline  Operations  Plan 
includes  the  ground  support  functional  organization,  mission  controller 
functional  requirements, Orbi ter/ Crew  functional  requirements,  and  operations 
support  requirements  Cost  estimates  are  presented  for  software  (ground  and 
airborne),  hardware,  facilities  and  services  which  are  directly  chargeable  to 
the  support  of  Tug  mission  operations 

9.1  MISSION  PLAN  DESCRIPTION 

This  section  defines  the  reference  mission  which  is  structured  to  include 
the  covering  set  of  mission  requirements  (required  mission  functions),  which 
provide  a basis  for  selecting  and  sizing  operational  support  elements 
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911  Covering  Set  of  Mission  Requirements 

Modular  timelines  were  developed  which  capture  the  scope  of  operational 
activities  surrounding  trajectory  based  events  Section  3 2 presents  and 
discusses  the  modules  making  up  the  modular  timelines  It  is  sufficient 
for  the  purposes  of  this  section  to  note  that  the  reference  mission  includes 
all  unique  operational  activities  of  a Tug  mission 

The  modules  are  the  Orbiter  Launch  Operations  module,  which  covers  the  period 
from  launch  preparations.  Tug  deployment,  checkout  and  ready  for  the  first 
engine  burn,  the  On  Orbit  Coast  module,  which  covers  the  interim  on-orbit 
navigation,  guidance  and  control  state  between  active  mission  modules,  the 
Mainstage  module,  which  is  utilized  each  time  a major  maneuver  is  required, 
the  Trimburn  module  which  is  utilized  whenever  the  main  engine  is  operated  in 
the  tankhead  idle  mode  or  pump  mode,  the  Payload  Placement  module,  which  covers 
the  activities  for  checkout  and  deployment  of  a Spacecraft,  the  Rendezvous 
module,  which  provides  the  operations  to  move  from  a Coplanar  phasing  orbit  to 
a point  sufficiently  near  a target  spacecraft  for  docking  initiation,  the 
Docking  module,  which  contains  the  operations  from  the  last  braking  gate  until 
latch,  the  Payload  Retrieval  module,  containing  the  operations  for  Spacecraft 
retrieval;  the  Service  module,  containing  operational  functions  for  Spacecraft 
servicing,  the  Orbiter  Retrieval  module,  containing  those  operational  functions 
performed  when  retrieving  the  Tug  and  Spacecraft,  and  the  Abort  module,  which 
contains  the  operational  functions  of  the  Orbiter  abort  modes. 

912  Dual  Deploy  - Single  Retrieval  Mission  Timeline 

The  mission,  chosen  as  the  reference  for  determining  control  center  requirements, 
deploys  two  satellites  120  degrees  apart  at  geosynchronous  altitude,  retrieves 
a satellite  from  geosynchronous  altitude  and  returns  to  the  Shuttle  rendezvous 
orbit  for  retrieval  by  the  Orbiter  This  mission  is  depicted  in  Figure  9 1 2-1 
In  achieving  the  objectives  of  the  mission,  the  Space  Tug  vehicle  must  be  con- 
trolled for  approximately  15  maneuvers  during  a seven  day  period 

Figure  9 1 2-2  presents  the  major  events  and  combined  TDRSS/STDN  Coverage 
timeline  for  the  out-bound  phase  of  the  reference  mission 

913  Ground  Coverage 

Since  all  ground  based  operations  are  totally  dependent  upon  the  transfer  of 
information  from  the  subject  vehicle  (in  this  case.  Space  Tug)  to  the  ground 
control  and  monitoring  site,  it  is  significant  to  evaluate  the  ground  coverage 
communications  capabilities  available. 

Two  systems  will  be  operational  during  the  Space  Tug  era  TDRSS  (Tracking 
and  Data  Relay  Satellite  System),  and  STDN  (Spacecraft  Tracking  and  Data 
Network)  Figure  9 1.3-1  presents  the  ascent  and  return  ground  track,  with  the 
areas  of  communication  coverage  indicated  by  the  solid  line  for  the  TDRSS  only 
Figure  9.1  3-2  presents  the  same  data  for  the  STDN-only  case  An  over-lay  of 
the  two  coverage  maps  indicates  that  both  TDRSS  and  at  least  3 stations  of 
STDN  (Madrid,  Goldstone,  Orroral ) are  required  for  total  communication  coverage, 
and  that  gaps  exist  in  the  coverage  of  either  system  viewed  independently 
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9 2 FUNCTIONAL  ORGANIZATION 

Figure  9 2 0-1  presents  an  overview  of  the  recommended  mission  control  organ- 
ization The  basic  line  structure  for  mission  control  organization  will  begin 
with  Mission  Director  at  the  apex  to  whom  reports  the  Orbiter  Operations 
Director,  the  Tug  Operations  Director  and  the  Spacecraft  Operations  Director 
Coordination  between  the  three  involved  control  agencies  will  be  direct,  with 
the  decision  authority  vested  m the  Mission  Director  to  resolve  conflicting 
subordinate  level  requirements.  The  chart  as  drawn  is  relevant  to  on-orbit 
operations  and  does  not  Include  the  launch  operations  involvement 

The  Tug  Operations  Director  is  responsible  for  all  aspects  of  control  of  the 
Tug  including  the  facilities  maintenance  and  operations,  vehicle  systems, 
flight  dynamics,  mission  planning  and  special  function  organization 

Reporting  to  the  Tug  Operations  Director  are  a Facilities  Management  group, 
a Vehicle  Systems  group,  a Flight  Dynamics  and  Mission  planning  group  devoted 
to  real-time  analysis  of  flight  dynamics,  real-time  retargetting  and  restruc- 
turing of  the  mission  and  the  preparation  of  the  initial  mission  plans,  and 
a Special  Functions  group.  The  Special  Function  operation  will  be  Spacecraft 
particular  or  experiment  related. 

9 2.1  Flight  Control  Organization 

The  flrght  control  organization  begins  at  the  second  tier  of  the  mission  control 
organization 

During  operational  periods  the  Tug  Operations  Director  assumes  total  authority 
over  all  control  center  functions,  including  the  Facilities  Management  group. 
During  non-operational  times,  the  Facilities  Supervisor  directs  the  support 
personnel.  This  report  is  concerned  only  with  the  operational  relationships. 

The  Flight  Control  Group  is  responsible  for  the  Tug  vehicle  and  the  successful 
accomplishment  of  its  mission.  It  is  divided  into  three  teams  Vehicle 
Systems,  Flight  Dynamics,  and  Special  Functions  The  Facilities  Management 
group  operationally  reports  to  the  Tug  Operations  Director  but  assumes  a 
support,  not  control  activity  Personnel  manning  the  positions  in  the  Flight 
Control  Group  will  be  experienced  engineering  personnel  with  corresponding 
design  and  test  responsibility  for  the  Tug  system  which  they  monitor  and 
control . 

Flight  Control  personnel  are  responsible  for  the  real-time  control  of  the  Tug. 
Preparation  for  these  responsibilities  requires  extensive  study  and  Control 
Center  “on-console"  training  for  each  mission  Backup  personnel  must  also 
be  equally  prepared  to  assure  timely  and  qualified  flight  support  continuation 
in  contingency  situations.  Flight  controllers  must  be  completely  abreast  of 
Tug  vehicle  systems,  the  Tug  Control  Center  data  display,  command  system  and 
all  details  concerning  the  specific  mission  being  flown. 

The  basic  responsibilities  of  each  team  position  are  listed  below 

Vehicle  Systems  Group  - The  Vehicle  Systems  Group,  reporting  to  the  Vehicle 
Systems  Engineer,  monitors  real-time  Tug  data  and  maintains  cognizance  of 
the  Tug  operational  status  The  team  is  functionally  divided  into  four  areas 
of  vehicle  responsibility  propulsion,  avionics,  networks,  and  communications. 
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Figure  92 0-1.  Tug  Mission  Control  Organization 


Flight  Dynamics/Mission  Planning  Group  - The  Flight  Dynamics  Group,  reporting 
to  the  Flight  Dynamics  Engineer,  is  responsible  for  Tug  vehicle  trajectory 
management  This  entails  the  continual  comparison  of  predicted,  actual  and 
desired  vehicle  trajectory  and  the  generation  of  corrective  maneuver  seq- 
ences.  Functional  divisions  of  the  group  are  Guidance  and  Dynamics 

Special  Functions  Group  - The  Special  Functions  Group  is  responsible  for 
monitoring  Spacecraft  status  and  most  activity  during  deployment  and  retrieval 
operations  It  is  probable  that  Special  Functions  Group  personnel  will  vary 
with  the  type  of  Spacecraft  being  serviced 

922  Facilities  Management  Organization 

The  Facilities  Management  Group  is  composed  of  three  teams.  Data  Systems, 
Maintenance  and  Operations  and  Software  Support  These  teams  insure  and 
are  responsible  for  control  center  readiness  and  operational  integrity. 

These  teams  report  directly  to  the  Facilities  Supervisor  during  mission 
operations 

The  Facilities  Management  Group  assists  the  Flight  Control  Group  with  commands, 
communications,  and  displays,  and  maintains  and  operates  all  equipment  within 
the  facility.  This  team  also  provides  logistic  support  for  continuous  control 
center  operation  The  Software  Support  Team  operational  responsibility  requires 
a continual  availability  of  personnel  capable  of  explaining  and/or  handling 
software  related  problems 

9.2  2 1 Organization  and  Reporting  Responsibility 

Figure  9 2 2-1  presents  the  Facilities  Management  Group  organization.  The 
organization  is  functionally  divided  into  three  groups  Data  Systems,  Mainten- 
ance and  Operations,  and  Software  Support  Division  is  along  functional  lines, 
although  there  is  overlap  between  all  three  groups. 

The  leader  of  the  Facilities  Management  group  is  known  by  two  titles,  used 
interchangeably,  as  the  Flight  Support  Director  or  as  the  Facilities  Super- 
visor This  is  indicative  of  the  dual  role  he  has  in  mission  operations. 

During  the  real-time  period,  he  reports  to  the  Flight  Director  and  is 
responsible  for  overall  support  to  the  Flight  Control  personnel  During  non- 
real-time  operations,  he  supervises  the  maintenance  and  checkout  of  the  facility 
equipment  In  both  roles,  the  Data  Systems,  Maintenance  and  Operations  and 
Software  Support  teams  report  administratively  to  him 

The  Data  System  Supervisor  oversees  the  activities  of  the  Command,  Telemetry 
and  Site  Select  Technicians. 

The  computer  operators,  computer  monitors,  data  flow  technician,  data  process- 
ing engineer,  voice  technician,  display  technician  and  TV  Technician  report 
directly  to  the  Facilities  Supervisor 

The  Software  Support  Supervisor  heads  a team  of  specialists  who  are  knowledgeable 
in  the  mission  profile,  vehicle  systems,  executive/control  center,  and  simulation 
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Figure  9 2 2-1  Facilities  flanagement  Group  Organization 


software.  These -personnel  provide  expertise  during  real-time  operations  to 
resolve  software-related  problems,  and  provide  update  and  mission-peculiar 
software  modifications  during  non-real -time  periods, 

9 2 2 2 Data  System  Support  Group  Responsibilities 

The  Data  Systems  Group  is  composed  of  personnel  who  are  actively  involved  in 
operating  the  support  systems  in  real-time.  These  personnel  interface  between 
the  flight  control  personnel  and  the  support  equipment,  acting  as  aides  and 
assistants  to  the  flight  control  personnel.  They  occupy  the  same  functional 
relationship  to  the  flight  controllers  as  an  aircrew  does  to  a pilot.  They 
are  operators,  as  opposed  to  maintenance  personnel,  who  interpret  data  in 
support  of  flight  controllers 

There  are  three  subdivisions  under  Data  Systems  telemetry,  command  and  site 
select. 

It  is  the  responsibility  of  the  telemetry  technician  to  monitor  telemetry 
data  flow  status  and  to  initiate  any  corrective  actions  required  to  maintain 
telemetry  data  flow  throughput  to  the  flight  control  consoles.  The  telemetry 
technicians  will  operationally  respond  to  any  flight  controller's  request  for 
telemetry  readouts  (e.g  , bit  circuit,  calibration  data,  bit-error  rate,  etc.), 
and  to  the  Facilities  Supervisor  through  the  Data  Systems  Supervisor 

The  command  technician  is  responsible  for  the  construction  of  command  loads 
in  the  appropriate  format  for  uplink,  the  transfer  of  that  load  into  an  up- 
link data  buffer,  and  monitoring  the  uplink  and  verification-of-receipt 
of  the  command.  The  command  technician  also  must  track  down  the  sources  of 
errors  in  the  command  data  flow  system,  and  cause  corrective  action  to  be 
initiated.  The  command  technician  responds  to  any  flight  controller  having  a 
command  panel  and  to  the  Facilities  Supervisor  through  the  Data  Systems 
Supervisor. 

The  site  select  technician  is  responsible  for  interface  between  the  Tug  Control 
Center  and  the  support  network  (TDRS  and  STDN).  He  will  coordinate  the 
selection  of  the  appropriate  site  to  receive  telemetry  or  to  uplink  commands 
to  the  Tug.  He  is  further  responsible  for  checking  the  operational  status  at 
each  site  and  for  planning  backup  or  alternate  routings  for  the  data  connections 
with  the  Tug.  He  is  responsible  for  providing  optimum  data  transfer  between 
the  Tug  and  the  Mission  Control  Center.  Th6  site  select  technician  reports  to 
the  Data  Systems  Supervisor,  and  has  no  direct  contact  with  the  flight  controller' 

The  Data  Systems  Supervisor  is  responsible  for  overall  operation  of  the  data 
systems  supporting  the  flight  controllers  He  manages  the  computer  operation, 
monitors  computer  status,  selects  the  on-line  CPU  and  monitors  switchover  In 
addition,  he  has  organizational  responsibility  for  the  performance  of  the 
telemetry  technician,  command  technician  and  site  select  technician. 

9. 2. 2. 3 Maintenance  and  Operations  Group  Responsibilities 

The  Maintenance  and  Operations  (M&O)  Group  is  composed  primarily  of  equipment 
maintenance  specialists  who  are  responsible  for  the  operability  of  all  Mission 
Control  Center  support  equipment. 
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The  M&O  personnel  have  no  direct  interface  with  the  flight  controllers  in  the 
operational  sense,  but  must  be  responsive  in  real-time  to  requests  to  fix  the 
equipment  In  the  pre-mission  non-operational  phases,  the  M&O  technicians 
must  perform  periodic  maintenance  on  the  equipment  and  conduct  proof-of-perform- 
mance  tests  of  equipment  operation  During  operational  periods,  the  M&O 
technicians  monitor  equipment  operation,  and  are  alert  to  malfunction  in- 
dications They  will  notify  the  Facilities  Supervisor  when  equipment  must 
come  off-line  for  repair,  and  will  coordinate  equipment  configuration  with  the 
Data  Systems  Technicians 

Computer  operators  operate  the  data  processing  equipment  associated  with  real- 
time flight  control  operations,  and  are  responsive  to  requests  from  the  Data 
System  technicians 

The  computer  monitors  are  responsible  for  mission  computing,  scheduling  and 
control  of  non-mission  job-shop  work,  CPU  performance  and  maintaining  of  the 
system  data  base  Computer  monitors  and  computer  operators  function  inter- 
actively to  maintain  the  data  processing  equipment  configuration  at  peak 
efficiency 

The  Data  Processing  System  Engineer  is  responsible  for  the  maintenance  of  the 
data  system  CPU  and  peripherals  This  function  is  best  performed  by  a 
maintenance  contractor  which  will  provide  a DPS  engineer  to  NASA  who  will 
respond  as  a member  of  the  Flight  Support  Team  This  function  requires  highly 
specialized  skills  and  training  normally  available  only  from  the  Data  Process- 
ing System  manufacturer.  During  operational  periods,  the  DPS  engineer  reports 
functionally  to  the  Facilities  Supervisor  During  non-mission  periods,  he 
executes  the  requirements  of  a Data  System  Maintenance  Contract 

The  Data  Flow  Technician  is  responsible  for  all  equipment  interfacing  between 
the  data  system  and  the  outside  world  This  will  include  all  MODEMS  and  line 
termination  equipment  which  interface  with  the  network  During  operational 
periods,  he  will  monitor  the  equipment  performance  and  select  the  terminals 
having  best  operational  characteristics  During  non-operational  periods,  he 
will  perform  periodic  maintenance  and  conduct  proof-of-performance  tests  on 
the  equipment 

The  Display  Technician  is  responsible  for  maintaining  the  equipment  which 
interfaces  with  the  flight  control  personnel,  consoles,  console  displays  and 
group  displays  During  operational  periods  he  monitors  the  operation  of  the 
equipment  and  stands-by  to  execute  immediate  replacement  or  repair  of  the 
equipment  During  non-operational  periods,  he  will  perform  periodic  main- 
tenance and  conduct  proof-of-performance  tests  The  Display  Technician 
directly  interfaces  with  and  is  responsive  to  direction  from  the  flight 
control  personnel  m real-time. 

The  Voice  Technician  is  responsible  for  all  voice  communications  internal  to 
the  control  center,  and  for  all  voice  communication  with  external  operational 
entities  He  is  the  primary  interface  with  the  common  commercial  carriers 
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which  provide  communications  service  to  the  Mission  Control  Center  The 
Voice  Technician  maintains  all  communications  loops  in  operational 
configuration 

9 2.2  4 Software  Support  Group  Responsibilities 

The  software  support  team  will  consist  of  high-level  software  personnel  who 
are  functionally  familiar  with  the  overall  software  and  its  capabilities 
Because  the  software  is  the  critical  element  in  achieving  the  Mission  objectives, 
the  software  support  team  must  be  able  to  respond  rapidly  to  software-related 
questions  and  actively  participate  with  flight  support  group  team  members  in 
the  effective  utilization  of  the  software  capabilities. 

The  software  support  supervisor  will  be  responsible  for  the  continuous 
software  support  and  development  activities  after  intial  delivery  of  the 
software  system  He  will  provide  the  interfaces  with  NASA  and  contractor 
personnel  for  all  software-related  functions  To  provide  the  necessary  inter- 
faces, he  will  have  a staff  of  software/hardware  systems  personnel  to  perform 
the  following  functions 

• Software  Reviews 

6 Configuration  Control 

• Software  Audits 

« Continuing  Customer  Interfaces 

• Project  Status  Reporting  (Costs  and  Schedules) 

• Document  Control 

A software  development  section  will  be  responsible  for  the  updating  of 
the  software  to  support  changing  requirements.  Previous  space  programs  of 
long  duration,  such  as  Apollo,  have  shown  that  the  software  within  the  control 
center  will  continue  to  evolve  throughout  the  lifetime  of  the  program.  The 
RTCC  software,  for  instance,  grew  in  size  by  a factor  of  50  percent  over  the 
lifetime  of  the  Apollo  program  This  growth  was  distributed  among  all  the 
elements  of  the  software 

To  address  the  requirements  for  continual  software  change,  the  software 
development  activity  has  been  organized  according  to  the  functional  software 
requirement  areas 

• Mission  Profile 

• Vehicle  Systems 

• Executive/Cpntrol  Center  Support 

t Simulation  and  Training 

Mission  Profile  - The  mission  profile  group  will  be  responsible  for  main- 
tenance and  support  ot  the  software  which  addresses  the  mission  profile 
function  These  software  elements  are 

• Orbit  Trajectory  Determination 

• Orbit  Trajectory  Computations 

• Mission  Planning 

Vehicle  Systems  - The  vehicle  systems  group  will  be  responsible  for  maintenance 
and  support  of  the  uplink  and  downlink  processing  software. 
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Executive/Control  Center  Support  - The  executive/control  center  support  areas 
of  the  control  center  software  will  be  highly  volatile  because  of  the  changing 
display  requirements  and  response  time  changes  as  a result  of  mission  changes 
and  vehicle  changes.  This  support  group  will  maintain  and  support  all  changes 
to  these  areas 

Simulation  and  Training  - The  simulation  and  training  software  group  will  be 
responsible  for  modifications  of  the  simulation  software  system  which  reflect 
changes  m mission  profiles  and  vehicle  configuration  In  addition,  this  group 
will  conduct  training  sessions  m software  capabilities  for  the  flight  support 
group  and  will  support  the  use  of  the  simulation  system  during  ground  controller 
training 

The  central  computers  of  the  control  center  will  be  utilized  for  real-time 
mission  support,  training  of  flight  support  personnel,  software  development, 
and  normal  jobshop  operations  It  is  assumed  that  for  cost  effectiveness,  the 
computer  operations  will  be  three  shift/day,  seven  day  a week  operations 

923  Recommended  Manning  Level 

The  following  paragraphs  describe  the  recommended  manning  levels  for  Tug 
operations  Major  divisions  in  manning  are  (1)  Facilities  Maintenance  or 
Flight  Support  Staff  and  (2)  Flight  Control  Staff 

9231  Facilities  Maintenance  or  Flight  Support  Staff 

There  are  33  personnel  required  to  staff  the  Facilities  Maintenance  or  Flight 
Support  organization  on  a continuing  basis  Table  9 2 3-1  presents  a break- 
down of  the  staff  requirements 

The  size  of  the  staff  is  established  by  the  real-time  support  requirements 
However,  the  staff,  during  non-mission  and  non-traimng  periods,  is  to  be 
utilized  to  perform  mission  preparations  and  maintenance  jobs  This  multi- 
plexing of  personnel  is  cost-effective  in  that  it  spreads  the  productive 
work  load  of  the  permanently  assigned  personnel  more  evenly  across  the 
operational  periods 


Table  9J!  3-1.  Flight  Support  Staff  Requirements 


POSITION 

MAX 

MANNING 

NO.  OF 
CONSOLES 

SHIFT 

DENSITY 

TOTAL 

REQ 

FLIGHT  SUPPORT  GROUP 
FLIGHT  SUPPORT  DIRECTOR 

1 

1 

2 

2 

DATA  SYSTEM  SUPERVISOR 

1 

1 

2 

2 

COMMAND 

1 

0 

2 

2 

TELEMETRY 

1 

1 

2 

2 

SITE  SELECT 

I 

0 

2 

2 

TV  TECH 

1 

0 

2 

2 

DATA  FLOW 

1 

1 

2 

2 

DPS  ENGINEER 

1 

0 

2 

2 

VOICE  TECH 

1 

0 

2 

2 

DISPLAY  TECH 

1 

0 

2 

2 

COMPUTER  SYSTEM  MONITORS 

2 

1 

2 

4 

COMPUTER  OPERATIONS 

3 

0 

2 

6 

COMPUTER  SUPPORT 

3 

0 

1 

3 

TOTALS 

18 

5 

- 

33 
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9232  Flight  Control  Staff 


There  is  a specific  minimum  staff  required  to  control  the  Tug  vehicle  during 
mission  operational  periods  For  the  Tug  program,  that  staff  requirement  is 
30  flight  control  engineers  The  flight  control  organization  is  a required 
sustaining  engineering  staff  which  may  be  utilized  during  non-mission  periods 
in  performing  preparation  tasks,  such  as  training,  scheduling,  and  interface 
type  operations  As  with  the  flight  support  staff,  the  spreading  of  effort 
across  the  period  of  operations  is  a cost-effective  utilization  of  the 
flight  control  staff  Table  9 2 3-2  presents  the  flight  control  staff 
requirements 


Table  9J  3-2  Flight  Control  Staff  Requirements 


POSITION 

MAX 

MANNING 

NUM  OF 
CONSOLES 

SHIFT 

DENSITY 

TOTAL 

REQ. 

FLIGHT  CONTROL  GROUP 
TUG  OPERATIONS  DIRECTOR 

1 

1 

2 

2 

VEHICLE  SYSTEMS  ENGINEER 

1 

1 

2 

2 

PROPULSION 

I 

1 

2 

2 

STAGE  SYSTEMS 

1 

1 

2 

2 

CONSUMABLES 

1 

0 

2 

2 

NETWORKS 

1 

1 

2 

2 

COMMUNICATIONS 

1 

0 

2 

2 

AVIONICS 

I 

1 

2 

2 

GUID  AND  NAV 

1 

0 

2 

2 

SEQUENCE 

l 

0 

2 

2 

GUIDANCE 

1 

1 

2 

2 

DYNAMICS 

1 

1 

2 

2 

TV/DOCKING 

1 

1 

2 

2 

FLIGHT  DYNAMICS  OFFICER 

1 

1 

2 

2 

SPECIAL  FUNCTIONS 

1 

1 

2 

2_ 

TOTALS 

15 

11 

30 

9.2  3.3  Derivation  of  Manning  Requirements 

Before  arriving  at  an  estimate  of  recurring  cost,  it  was  necessary  to  invest- 
igate the  impact  of  simultaneous  missions  and  mission  module  overlaps  on  the 
level  of  support  required 

To  accomplish  this  impact  analysis,  IBM  developed  a mission  density  factor 
program  This  program  creates  a launch  schedule  and  mission  module  timing 
schedule  from  which  the  overlap  of  missions  and  mission  modules  is  developed. 
At  the  same  time,  gaps  in  the  schedule  are  identified  which  can  be  used  for 
training  and  simulation  tasks 

Outputs  from  the  mission  density  factor  program  drive  the  following  dependent 
cost  relationships. 

Computer  Support  Personnel  - Establishes  the  hours  the  computer 

is  committed 
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Sustaining  Flight  Control 

Flight  Support  Personnel 

Flight  Control  Consoles 
Network  Rental 


- Establishes  the  number  of  shifts 
required  and  the  number  of  personnel 
required 

- Establishes  the  number  of  shifts 
required  and  the  number  of  personnel 
required. 

- Establishes  the  number  of  consoles 
required  by  type 

- Establishes  the  number  of  hours  required 
in  one  year  of  TV,  Telemetry,  Command  and 
Tracking  Service 


9234  Sustaining  Support  Personnel 

The  mission  density  function  establishes  the  computer  commit  hours  per  year, 
which  then  is  converted  to  equivalent  men  required  to  provide  computer 
support 


The  mission  density  function  also  establishes  the  shift  density  factor  for 
flight  support  personnel  The  level  of  effort  established  for  flight  support 
is  constant  No  provision  has  been  made  to  assign  other  duties  to  the  flight 
support  staff 

The  mission  density  function  provides  a shift  density  factor  and  console 
multiplier  which  are  combined  to  create  a manpower  requirement  estimate  The 
level  of  effort  established  for  flight  control  support  is  constant  No 
provision  has  been  made  to  assign  other  duties  to  the  flight  control  staff 

9235  Ground  Software  Maintenance 


Since  software  problems  will  be  identified  throughout  the  entire  software 
module  set,  it  is  necessary  to  provide  resident  personnel  familiar  with  every 
area  The  number  of  personnel  required  is  dependent  upon  the  size,  complexity, 
criticality  and  level  of  mission-to-mission  changes  for  the  program  Twenty- 
three  programmers  have  been  estimated  as  required  to  perform  the  ground  soft- 
ware maintenance 


9 2 3.6  Flight  Software  Maintenance 

Flight  software  maintenance  is  similar  to  ground  software  maintenance  m 
concept  It  is  necessary  to  maintain  a staff  of  personnel  who  are  familiar 
with  each  of  the  four  basic  programs,  and  to  maintain  capability  to  define, 
code  and  verify  the  flight  programs  Twenty-one  programmers  are  required  to 
supply  mission  modifications,  coding  and  verification  for  the  four  baseline 
programs 

9 3 FLIGHT  CONTROL  FUNCTIONAL  REQUIREMENTS 

The  following  paragraphs  define  the  nominal  and  contingency  functions  of  the 
Flight  Control  Organization. 
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93.1  Vehicle  Systems  Group 


The  vehicle  systems  group  is  required  for  Tug  mission  control.  The  vehicle 
system  group  is  formed  of  a leader  and  four  subordinate  organizations.  The 
leader,  the  Vehicle  System  Engineer,  is  responsible  for  all  vehicle  systems, 
and  will  coordinate  the  analysis  of  vehicle  systems  and  issues  all  commands 
to  the  vehicle  which  are  directly  related  to  hardware  functions,  as  opposed 
to  trajectory  shaping  functions.  The  vehicle  systems  engineer  is  a primary 
consultant  and  recommends  implementation  of  mission  rules  based  upon  the 
state  of  affairs  at  a given  time  during  the  mission 

Reporting  to  the  Vehicle  System  Engineer  is  the  propulsion  group,  which  is 
responsible  for  the  main  propulsion  system,  the  attitude  control  propulsion 
system,  pneumatics,  propellant  tank  management,  mam  engine  performance 
and  main  engine  support  devices,  maintaining  knowledge  of  consumables 
utilization,  structures  and  thermal  control  considerations. 

The  second  major  division  under  the  vehicle  systems  group  is  the  avionics 
support  team  The  avionics  support  team  is  responsible  for  the  analysis  of 
all  hardware  relevant  to  the  guidance,  navigation  and  control  system  and  the 
attitude  and  thrust  vector  control  systems  Two  suborgamzations  beneath  the 
avionics  organization  are  the  Guidance  and  Navigation  Engineer  and  the 
Sequential  Systems  Engineer  with  the  primary  division  between  those  two  being 
between  sensor  hardware  and  computational  hardware  analysis 

The  third  breakdown  beneath  the  vehicle  system  engineer  is  the  network 
responsibility  All  functions  relevant  to  the  electrical  power  capability, 
battery  charge,  fuel  cell  operation  and  electrical  loads  are  the  responsibility 
of  the  Networks  System  Engineer 

The  fourth  subdivision  is  the  Communications  System  Engineer.  This  engineer 
is  responsible  for  maintaining  cognizance  of  the  status  of  the  communications 
systems  for  uplink,  downlink,  and  tracking  functions  Additionally,  he  is 
responsible  for  the  generation  of  commands  and  the  coordination  of  uplink 
requirements  with  the  network  He  maintains  cognizance  over  the  signal 
conditioning,  multiplexers,  transducers,  and  RF  components  of  the  telemetry 
systems. 

Figure  9 3 1-1  presents  the  vehicle  systems  group  organization 
9.3.2  Flight  Dynamics  and  Mission  Planning  Group 

The  flight  dynamics  and  mission  planning  organization  is  concerned,  in  the  pre- 
mission period,  with  the  structure  and  generation  of  the  optimum  mission 
trajectory  based  upon  the  Payload,  Orbiter  and  Tug  operational  constraints 
In  real-time  the  flight  dynamics  organization  is  responsible  for  trajectory 
planning  and  shaping,  all  decisions  based  upon  trajectory  considerations, 
planning  of  maneuvers,  commanding  maneuvers,  plus  maintaining  knowledge  of 
the  Orbiter,  Payload  and  Space  Tug  'ephemerides. 

Figure  9. 3. 2-1  presents  the  Flight  Dynamics  and  Mission  Planning  Organization 
There  are  three  basic  subdivisions  beneath  the  flight  dynamics  organization 
Guidance,  Dynamics  and  Television/Docking  The  Guidance  engineer  is  responsible 
for  monitoring  vehicle  performance  during  guidance  phases,  the  analysis  of 
drift  in  references,  the  optimization  of  corrective  maneuver,  the  recommendation 
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Figure  931-1  Vehicle  Systems  Group  Organization 


Figure  9 3 2-1.  Flight  Dynamics  and  Hission  Planning  Organization 


of  command  action  to  accomplish  those  maneuvers,  and  the  selection  of  the 
optimum  guidance  scheme  for  a particular  mission  maneuver.  The  Dynamics 
engineer  is  responsible  for  maintaining  knowledge  of  vehicle  mass  characteristics, 
the  monitoring  of  the  trajectory,  and  the  overseeing  of  the  trajectory  com- 
putations which  result  in  the  ephemeris  tables  for  the  Space  Tug,  Payloads 
and  Orhiter.  The  Television/Docklng  engineer  is  responsible  for  establishing 
and  maintaining  video  data  flow  and  control  of  the  on-board  docking  aids,  the 
selection  of  cameras  as  necessary  to  support  the  docking  operation,  and  the 
mensuration  of  image  data.  He  will  also  be  responsible  for  all  near-m  termi- 
nal docking  phases  and  will  work  closely  with  the  Spacecraft  Operations  Center 
during  the  docking  operation 

9 3 3 Special  Functions  Qroup 

Provision  has  been  made  for  a "Special  Function"  group  to  be  incorporated  into 
the  basic  Tug  operations  organisation  m order  to  accommodate  experiment 
packages  or  unique  Spacecraft  missions  that  may  require  additional  specialists 
for  specific  functions  Figure  9 3 3-1  shows  the  Special  Functions  group 
organization 

The  one  permanent  member  of  the  Special  Function  group  is  the  Special  Functions 
engineer  who  will  be  responsible  for  all  payload  operations  from  predeployment 
monitoring  and  housekeeping  through  interface  with  the  principal  investigator. 
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SPECIAL  FUNCTIONS  ENGINEER 

• RESPONSIBLE  FOR  ALL  SPACECRAFT 
OPERATIONS 
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Figure  9 3 3-1.  Special  Functions  Group 
934  Facilities  Management  Group 

The  Facilities  Management  Group  (reference  Figure  9.2  2-1}  is  responsible 
for  providing  the  necessary  data,  command  and  network  configuration  coor- 
dination required  to  support  the  Tug  mission  All  scheduling  interfaces 
with  the  network  operations  will  be  conducted  by  this  team  Additionally, 
all  hardware  and  software  maintenance  required  in  the  Tug  control  center  will 
be  provided  by  the  facility  management  group 

There  are  three  basic  organizational  entities  reporting  to  the  facilities 
management  supervisor  Those  organizations  are  the  data  system  subgroup, 
the  maintenance  and  operations  subgroup  and  the  software  support  team 

The  data  system  supervisor  has  three  groups  reporting  to  him,  a command 
group,  a telemetry  group,  and  a site  select  group  The  data  system  supervisor 
collectively  has  responsibility  for  overall  operation  of  the  computer  complex 
and  is  responsible  for  telemetry,  tracking  and  command  interface  with  the 
support  network 

The  maintenance  and  operations  organization  is  responsible  for  the  operability 
of  the  data  processing  and  display  equipment,  communications  equipment,  the 
overall  facility  capabilities  and  the  mission  support  logistics  The  group 
has  seven  specialists  computer  operators,  a data  flow  specialist,  a data 
processing  system  maintenance  engineer,  a computer  monitor,  television  tech- 
nician, display  technician,  and  voice  technician 

The  software  support  team  is  responsible  for  maintaining  the  support  soft- 
ware m an  operable  condition,  coordinating  the  problems  with  the  flight 
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director  as  required  and  for  answering  of  all  software  related  questions, 
including  operational  utilization 'of  the  software  by  the  flight  controllers 

935  Ground  Software  Support  Group 

It  is  reasonable  to  assume  that  there  will  be  changes  from  mission  to  mission 
in  the  Tug  Control  Center  software.  To  effect  these  changes,  a Software 
Support  Group  will  be  required.  This  organization  is  depicted  in  Figure 
9 3 5-1  and  will  be  discussed  in  the  following  paragraphs. 

9351  Project  Manager/ Project  Office 

The  software  project  manager  will  be  responsible  for  the  continuous  software 
support  and  development  activities  after  initial  delivery  of  the  software 
system.  He  will  provide  the  interfaces  with  NASA  and  other  contractor 
personnel  within  the 'control  center  for  all  control  center  software-related 
functions.  To  provide  the  necessary  interfaces,  he  will  have  a project  office 
staff  of  five  software/hardware  systems  personnel  to  perform  the  following 
functions*  * 

• Software  Review 

• Configuration  Control 

» Software  Audits 

e Continuing  Customer  Interfaces 

• Project  Status  Reporting  (Costs  and  Schedules) 

• Document  Control 

9 3 5.2  Software  Development  Section 

The  software  development  section  will  be  responsible  for  the  continual  updating 
of  the  software  to  support  changing  requirements.  Previous  space  programs  of 
long  duration,  such  as  Apollo,  have  shown  that  the  software  within  the  control 
center  will  continue  to  evolve  throughout  the  lifetime  of  the  program.  The 
RTCC  software,  for  instance,  grew  in  size  by  a factor  of  50  percent  over  the 
lifetime  of  the  Apollo  program.  This  growth  was  distributed  among  all  the 
elements  of  the  software. 

To  address  the  requirements  for  continual  software  change,  the  software 
development  activity  has  been  organized  according  to  the  functional  software 
requirement  areas  As  shown  in  Figure  9. 3. 5-1,  these  areas  are 

c Mission  Profile 

• Vehicle  Systems 

• Executive/Cgntrol  Center  Support 

s Simulation  and  Training 

9.3  5.3  Mission  Profile 

The  mission  profile  area  will  be  responsible  for  maintenance  and  support  of 
the  software  which  addresses  the  mission  profile  function.  These  software 
elements  are 
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• RESPONSIBLE  FOR  OVERALL 
TOC  SOFTWARE  ACTIVITY 


• SOFTWARE  REVIEWS 

• CONFIGURATION  CONTROL  BOARDS 

• SOFTWARE  AUDITS 

• CUSTOMER  INTERFACE 

• PROJECT  STATUS  REPORTING 
© DOCUMENT  CONTROL 


SOFTWARE 

PROJECT 

OFFICE 


• DESIGN  OF  CHANGES 


SOFTWARE 

DEVELOPMENT 

SECTION 


• IMPLEMENT  CHANGES  INTO 
SOFTWARE 

• CONFIGURATION  CONTROL 


COMPUTER 

OPERATIONS 

SECTION 


• MAINTAIN  & UPDATE 
CENTRAL  COMPUTERS 

• ADMINISTRATIVE  SERVICES 

• JOB  SHOP  OPERATIONS 


• SOFTWARE  TESTING/ 
VERIFICATION 


• 3 SHIFT/DAY  7 DAYS/ 
WEEK  OPERATION 


• DOCUMENTATION 

• DELIVERY 


MISSION  SUPPORT/ 
TRAINING  OPERATIONS 


Figure  935-1  Software  Support  Group 


• Orbit  Trajectory  Determination 

• Orbit  Trajectory  Computations 

• Mission  Planning  ' 

• Docking 

9. 3. 5. 4 Vehicle  Systems 

The  vehicle  systems  group  will  be  responsible  for  maintenance  and  support  of 
the  uplink  and  downlink  processing  software  of  the  Tug  Control  Center. 

9 3 5.5  Executive/Control  Center  Support 

The  executive/control  center  support  areas  of  the  software  will  be  highly 
volatile  because  of  the  changing  display  requirements  and  response  time 
changes  as  a result  of  mission  changes  and  vehicle  changes.  This  support 
group  will  maintain  and  support  all  changes  to  these  areas 

9 3 5.6  Simulation  and  Training 

The  simulation  and  training  software  group  will  be  responsible  for  modifications 
of  the  simulation  software  system  which  reflect  changes  in  mission  profiles 
and  Tug  vehicle  configuration.  In  addition,  this  group  will  conduct  training 
sessions  in  software  capabilities  for  the  flight  support  group  and  will  support 
the  use  of  the  simulation  system  during  flight  controller  training. 

9. 3. 5. 7 Computer  Operations  Section 

The  central  computers  of  the  control  center  will  be  utilized  for  real-time 
mission  support,  training  of  flight  support  personnel,  software  development, 
and  normal  jobshop  operations  It  is  assumed  that  for  cost  effectiveness, 
the  computer  operations  will  be  three  shift/day,  seven  day  a week  operations, 
and  is  staffed  accordingly.  Included  within  this  section  are  keypunch  services, 
tape  librarians,  administration  personnel,  management  personnel,  customer 
engineers,  as  well  as  the  computer  operations  personnel 

9 4 ORBITER  CREW  FUNCTIONAL  REQUIREMENTS 

Since  the  Space  Tug  is  recommended  to  be  designed  as  a highly  autonomous 
vehicle,  there  is  minimal  interface  with  the  Orbiter  crew  What  interaction 
exists,  is,  for  the  most  part,  monitoring  of  caution  and  warning  parameters 
and  backup  to  critical  sequences  in  the  event  of  contingency  situations 

9.5  OPERATIONS  SUPPORT  REQUIREMENTS 

This  section  summarizes  the  hardware,  software,  and  data  system  required  to 
support  real-time  Tug  operations 

9.5  1 Airborne  Operations  Support  Hardware 

The  Tug  Avionics  System  has  the  dominant  impact  upon  mission  operations.  The 
implementation  of  control  decisions  can  be  shifted  between  the  onboard 
avionics  and  the  ground  based  electronics.  This  shift  is  a function  of  the 
level  of  autonomy  to  which  the  Tug  is  designed. 
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In  general,  the  shift  of  control  authority  to  the  onboard  system  is  desirable, 
since  the  implementation  of  any  control  on  the  ground  carries  with  it  a heavy 
overhead  for  transfer  of  data  from  the  vehicle  relative  to  its  physical 
conditions  to  a ground  based  information  assimilator  This  overhead  (tracking, 
telemetry,  command,  etc  ) contributes  nothing  to  the  decision  processes 

Figure  9 5 1-1  presents  the  Space  Tug  avionics  system,  which  houses  the 
airborne  operations  support  hardware 

The  basic  avionics  configuration  provides  a centralized  digital  computer  with 
a data  bus/DIU  system  for  data  acquisition  and  distribution  The  configuration 
shown,  along  with  the  appropriate  software,  provides  a high  capability  vehicle 
capable  of  autonomous  operation  (except  for  docking,  which  is  ground-aided) 

The  avionic  system  is  basically  dual  redundant  The  following  is  a brief  des- 
cription of  each  subsystem 

Data  Management  - The  DMS  provides  a fault  tolerant  memory  configuration  in 
conjunction  with  dual  CPU's  and  IOP's  to  provide  the  storage,  processing  and 
input/output  operations  for  the  Tug  vehicle  The  CIU,  data  bus  and  4 DIU's 
provides  command  and  data  routing  and  the  gathering  and  formatting  of  telemetry 
data  The  tape  recorder  records  maintenance  data 

GN&C  - The  laser  gyro  IMU,  in  conjunction  with  the  DMS,  provides  the  basic 
inertial  reference  system  for  the  Tug  The  interfermetric  landmark  tracker 
(ILT)  provides  onboard  state  vector  update  capability  and  the  star  tracker/ 
sun  sensor  combination  provides  autonomous  attitude  update  capability  The 
laser  rate  gyros  aid  flight  control  operations 

Rendezvous  and  Docking  - The  scanning  laser  radar  provides  autonomous  ren- 
dezvous capability,  while  the  man-m-the-loop  LLLTV  system  provides  for 
Spacecraft  docking  and  visual  inspection  of  Spacecraft 

Communications  - A phased  antenna  system  with  dual  redundant  decoders  and 
transponder  provide  omnidirectional  and  directional  capability  for  Tug  tele- 
try,  tracking  and  command  external  interface 

Electrical  Power  - The  Tug  power  is  generated  by  redundant  fuel  cells  with 
an  emergency  backup  battery 

952  Ground  Operations  Support  Hardware 

The  hardware  analysis  is  divided  into  two  parts,  i e , that  utilized  by  the 
mission  support  staff  (consoles,  communication  panels,  etc  ) and  that  re- 
quired for  the  Tug  Control  Center  Data  System 

9 5 2.1  Data  System 

The  data  system  in  the  Tug  Control  Center  is  the  system  by  which  incoming, 
outgoing,  and  mtercenter  intelligence  is  processed,  routed  and  managed.  The 
data  system  is  depicted  in  Figure  9 5 2-1.  The  computer  is  the  central  element 
of  the  system,  and  because  of  its  significance,  it  has  been  addressed  separately. 
The  remaining  elements  of  the  system  are  discussed  in  the  following  paragraphs 
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Figure  9.5. 1-1.  Space  Tug  Avionics  System 
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Figure  9.52-1.  TOC  Data  System 

Communications  Controller  - The  communications  controller  is  a device  required 
for  buffering  and  routing  input  and  output  data  between  the  central  computer 
and  the  data  line  terminations  (MODEMS).  Incoming  telemetry  and  tracking  data 
is  checked  for  transmission  errors,  error  encoding  removed  and  then  formatted 
for  transfer  to  the  central  computer.  Outgoing  command  data  is  received  from 
the  central  computer,  encoded  into  proper  format  and  then  transferred  to 
outgoing  transmission  facilities.  The  unit  is  essentially  a switch  and 
storage  facility  for  incoming  and  outgoing  data. 

Modulator/Demodulators  (MODEM'S)  - MODEMS  are  devices  required  for  interfacing 
with  Tug  Control  Center  transmission  lines.  These  devices  serve  the  function 
of  modulation  conversion  between  transmission  line  format  and  the  computer 
system  format  for  both  incoming  and  outgoing  information. 

Master  Clock  - The  master  clock  is  an  independent  time  source  supplying 
master  time  (GMT)  to  the  central  computer  system.  The  central  computer  will 
then  generate  the  differential  times  needed  for  mission  control.  The  master 
clock  will  also  contain  a receiver  for  synchronization  to  the  National  Bureau 
of  Standards  master  clock. 

Console  Discrete  Interface  Device  - This  unit  serves  as  an  interface  between 
the  central  computer  and  the  support  staff  consoles.  It  compiles  discrete 
and  digital  signals  into  formats  acceptable  for  use  by  the  central  computer. 
These  signals  include  command  execute  pushbuttons,  display  request  signals, 
computer  control  pushbuttons  and  miscellaneous  computer  control  discretes. 

For  Tug  Control  Center  usage,  this  unit  will  be  capable  of  processing 
approximately  1200  individual  signals. 
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Digital  and  Discrete  Drivers  - The  digital  and  discrete  drivers  are  interface 
devices  between  the  central  computer  and  console  displays  which  receive  digital 
and  discrete  word  outputs,  de-multiplex  these  words  and  then  drive  individual 
lamps,  readouts,  etc  These  drivers  are  required  for  all  status  and  event 
lites,  command  pushbutton  indication  lites,  digital  readouts,  and  clock  read- 
outs For  Control  Center  usage,  the  system  will  handle  approximately  2000 
individual  discretes 

Digital  Ty  Equipment  - Digital  TV  Equipment  (DTE)  is  required  to  convert 
computer  generated  display  data  into  video  and  video  associated  signals 
compatible  with  the  support  staff  console  TV  monitors  The  DTE  combines 
static  background  format  data  stored  by  the  computer  with  the  dynamic  data 
being  processed  by  the  computer  in  real-time  and  formats  the  information 
for  display  on  the  TV  monitors  Display  refresh  is  performed  by  the  DTE 
Only  updated  information,  that  is,  information  which  has  changed  since  the 
last  refresh  cycle,  is  transferred  from  the  computer  to  the  DTE 

Video  Switching  Equipment  - The  Video  Switching  Equipment  distributes  Digital 
TV  data  from  the  computer  to  individual  console  TV  monitors.  Live  and 
recorded  Tug  TV  will  also  be  routed  through  the  video  switch  to  the  support 
staff  consoles  as  required  during  the  mission.  Scan  conversion  provisions 
will  be  provided  to  make  commercial.  Tug  video  and  display  systems  compatible. 

Computer  Terminal  Equipment  - During  a Tug  mission,  some  of  the  communications 
between  the  support  staff  (particularly  flight  controllers)  and  the  central 
computer  can  be  conducted  most  efficiently  using  standard  terminal  equipment. 

These  terminals  consist  of  a Manual  Entry  Device  (MED)  and  a CRT  display. 
Nominally,  one  display  control  unit  (interfacing  unit  to  the  computer)  will 
be  required  for  each  combination  of  six  of  these  terminals 

Teletype  Printer/Keyboard  (TTY)  - A TTY  Printer/ Keyboard  will  be  required  m 
the  Control  Center  for  general  administrative  message  receipt  and  generation. 

Communication  Equipment  - This  equipment  provides  voice  communications  throughout 
the  Control  Center  and  interfaces  with  external  commercial /common  carrier 
lines  For  Tug  operation,  a central  switchboard  will  be  required  to  provide 
the  following 

• 30  internal  loops 

• 15  external  connections 

• 10  PABX  stations 

The  PABX  will  be  configured  such  that  no  more  than  five  positions  will  have 
the  same  rotary  number. 

Computer  Peripheral  Equipment  - The  central  computer  will  require  standard 
peripheral  equipment  in  addition  to  the  Central  Processor  Unit  (CPU)  and 
memory  Standard  peripheral  devices  such  as  tape  drives,  disc  storage, 
channel  control,  line  printer,  card  reader  and  interface  adapters  will  be 
configured  for  Control  Center  support. 
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9 5 2 2 Support  Staff  Hardware  Requirements 

The  mission  support  analysis  discussed  in  this  document  delineates  various 
positions  and  their  responsibilities  to  support  a Tug  mission  To  effect 
the  support  from  these  personnel  will  require  a means  whereby  information  can 
be  made  available  to  them  for  decision  and  action 

Dissemination  of  this  information  is  achieved  by  displaying  the  information 
to  the  support  staff  in  the  form  of  TV  displays,  discrete  light  indicators, 
meters,  etc  For  convenience,  pertinent  indicators  and  computer  driven  TV 
displays  are  lodged  in  operator  consoles  according  to  the  requirements  of 
that  position 

Table  9 5 2-1  summarizes  the  equipment  necessary  for  each  position  to  per- 
form the  required  duties  assigned  to  it 

953  Ground  Operations  Support  Software 

The  Tug  Control  Center  Software,  which  resides  m the  central  computer, 
provides  centralized  processing  of  telemetry  inputs  received  from  the 
ground  network  and  performs  other  complex  mathematical  and  logical  func- 
tions in  support  of  flight  controllers  In  addition,  software  will  exist  to 
(1)  provide  a normal  computer  center  jobshop  environment  when  not  supporting 
the  real-time  Tug  mission,  and  (2)  to  provide  simulation  capability  in  support 
of  software  development,  ground  controller  training,  and  procedure  verification 
The  principal  emphasis  within  this  discussion  of  the  Tug  Control  Center  Software 
will  be  on  the  Tug  mission  support  areas  of  real-time  processing  and  simulation 
activity  prior  to  actual  flight 


The  mission  support  software  consists  of  several  interdependent  application 
subsystems  operating  in  real-time  to  satisfy  the  overall  support  requirements 
of  the  control  center  The  interrelationships  of  the  control  center  hardware 
and  software  required  to  satisfy  the  support  role  are  shown  in  Figure  9 5.3-1 

In  addition  to  defining  the  Control  Center  functional  software  specifica- 
tion, the  establishment  of  the  overall  size  of  the  software  is  required.  This 
sizing  information  will  be  later  used  in  costing  of  software  development  and 
in  establishing  the  specific  central  computer  size  required  to  support  the 
Control  Center.  Because  of  costing  differences,  the  software  size  will  be 
presented  in  the  form  of  computer  words  for  instruction  utilization  and  those 
used  for  data  allocation  The  differentiation  between  data  and  instruction 
definitions  is  shown  m Table  9 5 3-1  With  each  of  the  paragraphs  which 
discuss  the  Control  Center  software  requirements,  the  corresponding  size  in- 
formation will  be  provided 

The  Control  Center  mission  support  software  has  been  subdivided  into  four 
major  functional  areas  for  discussion  in  this  report  These  areas  are 
(1)  vehicle  systems,  (2)  mission  profile,  (3)  control,  and  (4)  simulation. 
These  four  subdivisions  have  been  further  divided,  as  shown  in  Figure 
9 5.3-2,  and  will  be  discussed  in  the  order  shown. 
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Table  9 5J-1.  Support  Staff  and  Flight  Control  Staff  Equipment  Allocation 


POSITION 

MAXIMUM 

MANNING 

CONSOLES 

COMM. 

PANEL 

TV 

MONITORS 

EVENT 

MODULES 

SUMMARY 

MESSAGE 

KEYBOARD 

COMMAND 

PANEL 

TV 

DISPLAY 

CONTROL 

FLIGHT  DIRECTOR 

1 

1 

1 

2 

4 

1 

1 

VEHICLE  SYSTEMS  ENGINEER 

1 

1 

1 

2 

4 

1 

i 

7 

PROPULSION 

1 

h 

1 

1 

2 

1 

1 

1 

STAGE  SYSTEMS 

1 

h 

1 

1 

2 

1 

SEQUENCE 

1 

h 

1 

1 

2 

1 

CONSUMABLES 

1 

h 

1 

1 

2 

7 

NETWORKS 

1 

h 

1 

1 

2 

1 

COMMUNICATIONS 

1 

h 

1 

1 

2 

1 

1 

AVIONICS 

1 

h 

1 

1 

2 

1 

7 

GUIDANCE  & NAVIGATION 

1 

H 

1 

1 

2 

1 

FLIGHT  DYNAMICS  OFFICER 

1 

1 

1 

2 

4 

1 

7 

7 

GUIDANCE 

1 

1 

2 

2 

4 

1 

1 

DYNAMICS 

1 

1 

2 

2 

4 

1 

X 

1 

SPECIAL  FUNCTIONS 

1 

1 

1 

2 

4 

1 

7 

7 

TELEVISION/DOCKING 

1 

1 

1 

1 

2 

1 

JL 

1 

FLIGHT  SUPPORT  DIRECTOR 

1 

1 

1 

2 

4 

1 

1 

1 

DATA  SYSTEM  SUPERVISOR 

1 

h 

1 

I 

2 

1 

1 

COMMAND 

1 

\ 

1 

1 

2 

7 

TELEMETRY 

1 

h 

1 

1 

2 

1 

7 

SITE  SELECT 

1 

h 

1 

1 

2 

X 

COMPUTER  SYSTEM  MONITORS 

2 

lh 

3 

3 

6 

1 

7 

DATA  FLOW 

1 

h 

1 

1 

2 

1 

X 

1 

DPS  ENGINEER 

1 

X 

VOICE  TECH 

1 

DISPLAY  TECH 

1 

TELEVISION  TECH 

1 

COMPUTER  OPERATIONS 

3 

SOFTWARE  SUPPORT  TEAM 

3 

TOTAL 

33 

16 

26 

31 

62 

17 

8 

16 

Figure  9 5 3-1  TOC  Software  Functional  Interfaces 


9 5.3  1 Vehicle  System  Software 

To  provide  monitoring  and  control  functions,  the  Control  Center  is  required 
to  maintain  interface  with  the  Tug  vehicle  through  the  telemetry  downlink 
system  and  the  digital  command  uplink  system.  The  application  software  systems 
which  provide  these  interface  capabilities  are  the  downlink  processing  and 
uplink  processing  software  These  critical  subsystems  are  discussed  in  the 
following  paragraphs 

95311  Downlink  Processing 

The  downlink  processing  subsystem  processes  telemetry  data  received  via  the 
STDN  (or  TDRSS)  from  the  Tug  vehicle  The  data  is  processed  in  real-time 
and  the  results  displayed  to  Flight  Control  personnel  for  system  evaluation. 

The  downlink  processing  capability  is  comprised  of  real-time  processing,  and 
telemetry  support  processing,  each  of  which  will  be  discussed  in  subsequent 
paragraphs  This  process  is  depicted  in  Figure  9 5.3-3  Size  of  the  downlink 
processing  software  is  shown  in  Table  9.5  3-2 


PA®  is 

P°0R  quality 
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Table  9 53  1 Instruction  /Data  Definition 


INSTRUCTION/DAT*  EXAMPLE 

PPCBLEf*  Evaluate  y as  a function  of  tire  (t)  according  to 
the  following  exp^essior 

y = A + Bt  + Ct2  + Dt2 

Where  A,  B,  C,  and  D are  coefficients  which  determine 
the  particular  relationship  between  y and  t 


PROGRAMMING 

INSTRUCTIONS  are  the  sequence  of  machine  operations 
required  to  evaluate  the  expression  for  y 

DATA  consists  of  the  coefficients  A,  B,  C,  and  D 


DISCUSSION 

Once  the  instructions  for  the  evaluation  have  been 
tested,  data  can  be  changed  without  retesting  of  the 
instruction  logic  This  reduces  the  cost  of  changing 
data  words,  whereas  selection  of  a new  evaluation 
technique  will  require  complete  redevelopment 


Real-Time  Telemetry  Processing 

The  real-time  processing  capability  consists  of  software  to  perform  decom- 
mutation and  conversion  of  input  telemetry  parameters  utilized  in  real-time 
support  of  mission  controllers  and  in  performing  analysis  on  telemetry 
parameters  to  provide  system  status  data  regarding  the  Tug  vehicle.  This 
process  is  shown  in  Figure  9.5  3-4  The  major  processing  performed  is 
discussed  in  the  following  paragraphs 

Dacommutation  - The  decommutation  module  of  the  downlink  processor  processes 
real-time  telemetry  data  at  the  input  message  level  Each  message  is  validated 
for  proper  sequence  by  the  ground  site  Formats  of  input  messages  are  also 
validated 

Through  the  use  of  a decommutation  table,  generated  offline  and  loaded  upon 
receipt  of  an  input  message,  the  decommutation  module  will  unpack  data  from 
the  input  stream  into  data  buffers  utilized  by  telemetry  conversion  software. 

In  addition,  information  pertaining  to  the  location  within  the  buffer  of 
data  is  provided  to  user  programs. 
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Table  9.5 \3-2.  Down/mk  Processing  Summary 


FUNCTION 

NO  QF 
INSTRUCTION 
WORDS  ‘ 

NO.  OF 

DATA 

WORDS 

TOTAL 

REAL-TIME  TELEMETRY  PROCESSING 

DECOMMUTATION 

5,035 

1,560 

6,595 

DATA  CONVERSION 

9,265 

6,060 

15,325 

TELEMETRY  SUPPORT 

DATA  REDUCTION 

28,305 

2,520 

30,825 

DATA  ANALYSIS 

25,585 

2,400 

27,985 

TOTALS 

68,190 

- 

12,540 

80,730 

IUS  CONTROL 
CENTER 


• 

LIMIT  SENSING 

• 

SYSTEM  PERFORMANCE 

• 

TRENDING 

• 

DISPLAYS 

• 

PLOTS 

• 

ALARMS 

• 

ETC 

i 

MISSION  PROGRAM 


VEHICLE  | 

SYSTEMS  1 


PERFORMS 

• DECOMMUTATION  OF  TM  DATA 

• ANALYSIS  OF  TM  DATA 

• PERFORMANCE  MONITORING 


Figure  9.S.3-3.  Downlink  TM  Processing 
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Figure  9534  Real-Time  W Processing 


Data  Conversion  - For  use  within  the  software  subsystems  and  for  display 
to  mission  controllers  and  other  mission  support  personnel,  the  raw  input 
telemetry  data  must  be  converted  into  a meaningful  format  This  function  is 
performed  by  the  data  conversion  modules  of  the  downlink  processor  through 
the  following  steps 

• Data  formatting 

• Check  for  error  conditions  and  set  appropriate  status  indicators 

• Maintenance  of  history  buffers  of  input  data 

• Perform  data  conversions 

• Store  converted  data  into  appropriate  data  areas 

• Limit-sensing  of  converted  data 

Telemetry  Support  Processing 

The  telemetry  support  processing  software  is  designed  to  operate  in  a non-real- 
time  environmnet  and  is  largely  dedicated  to  the  data  reduction  and  data  analysis 
of  all  parameters  received  via  the  downlink  system  The  input  to  the  telemetry 
support  system  is  the  telemetry  history  data  gathered  in  real-time  and  saved  on 
auxiliary  storage  devices  for  offline  analysis.  Outputs  of  the  analysis  are 
reports  for  use  by  fhght  controllers  in  evaluating  overall  system  performance 

Another  function  performed  by  the  telemetry  support  software  is  the  generation 
of  tables  to  be  utilized  for  real-time  telemetry  processing  These  tables 
contain  the  attributes  required  in  processing  each  telemetered  parameter 
and  include  such  characteristics  as  scaling,  calibration  information,  and 
limits  on  range  Also  included  are  critical  event  tables  for  use  in  monitor- 
ing correct  Tug  operation  in  real-time  and  display  format  tables  for  defining 
console  support  requirements 

9.5  3.1.2  Uplink  Processing 

Uplink  processing  involves  the  formatting  and  transmission  of  commands  to 
the  Tug  vehicle  via  the  STDN  Cor  TORS)  and  the  verification  of  network 
responses  to  those  commands.  The  uplink  processing  software  is  comprised 
of  three  major  functional  areas  whose  responsibilities  are  (1)  format  and 
transmit  all  commands,  (2)  validate  the  transmitted  commands  and  update 
command  status  displays,  and  (3)  perform  site  and  data  management  The 
overall  functioning  of  the  uplink  processing  software  is  discussed  in  the 
following  paragraphs  A functional  diagram  of  the  uplink  processing  is  shown 
in  Figure  9 5 3-5  and  the  size  of  the  software  is  shown  in  Table  9.5  3-3. 

Command  Processing  Control  Program  - The  command  processing  control  program  is 
active  Tn  all  aspects  of  uplinx  processing  and  performs  the  following  functions 

• Responds  to  requests  for  uplink  processing 

• Retrieves  and  initializes  tables 

• Handles  communications  among  program  modules  utilized  in  uplink 
processing 

Its  overall  prime  function  is  to  control  the  operations  required  in 
response  to  requests  for  uplink  processing  functions 
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Figure  9 5 3-5.  TOC  Uplink  Processing 


Command  Generation  Program  - The  command  generation  program  examines  the 
input  request  and  determines  the  command  which  is  required  Using  data  from 
the  command  processing  data  table  and  data  acquired  from  other  ground  center 
software,  the  command  is  then  formatted  for  transmission  Prior  to  trans- 
mission, appropriate  display  tables  are  updated  for  mission  controller 

verification  of  correct  command  format  The  command  is  then  transmitted  to 
the  appropriate  remote  site  ground  station  for  uplink  to  the  Tug  vehicle. 
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Table  9 5.3-3.  Uplink  Processing  Size 


FUNCTION 

NO  OF 

INSTRUCTION 

WORDS 

NO  OF 

DATA 

WORDS 

TOTAL 

SITE  MANAGEMENT 

5,780 

7,800 

13,580 

DIGITAL  COMMAND  PROCESSING 

27,200 

6,840 

34,040 

TOTALS 



32,980 

14,640 

47,620 

Command  Val i dati on  Program  - All  commands  transmitted  to  remote  sites  are 
' echoed 1 back  to  the  ground  control  center  with  status  information  Indicating 
whether  the  command  was  accepted  or  not.  In  addition,  the  command  validation 
program  has  a "time-out"  feature  in  the  event  that  no  response  is  obtained 
from  the  remote  site  within  the  specified  interval 

The  command  validation  program  processes  the  'echo'  messages  and  will  print 
messages  for  those  commands  flagged  as  invalid  These  print  messages  will 
indicate  the  command  as  well  as  the  reason  for  invalidity  Command  messages 
successfully  received  by  remote  sites  and  verified  are  logged  into  command 
history  tables. 

Site  and  Data  Management  - The  site  and  data  management  program  updates  the 
command-related  displays  for  use  by  mission  controllers  The  displays  are 
only  updated  upon  request  for  command  processing  and  contain  the  following 
types  of  information 

• Site  management  command  history 

• Overall  command  history 

t Critical  parameter  changes  executed  through  the  uplink  system 

• Failure  analysis  history 

9 5 3.2  Mission  Profile  Software 

The  mission  profile  software  of  the  ground  control  center  is  primarily  con- 
cerned with  trajectory-associated  functions  The  functional  requirements 
satisfied  within  the  mission  profile  software  are  listed  below  and  are 
discussed  in  more  detail  in  subsequent  paragraphs. 

• Orbit  trajectory  computations 

t Mission  Planning 

The  overall  estimated  size  of  the  mission  profile  software  is  shown  in 
Table  9. 5. 3-4.  In  addition,  major  subdivisions  of  the  software  are  shown. 
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Table  953-4  Mission  Profile  Software  Sizing 


FUNCTION 

NO  OF 

INSTRUCTION 

WORDS 

NO  OF 

DATA 

WORDS 

TOTAL 

ORBIT  TRAJECTORY  COMPUTATIONS 

EPHEMERIS  GENERATION 
AND  CONTROL 

22,100 

4,050 

26,150 

STATION  CONTACT 
CONTROL 

8,640 

500 

9,140 

MISSION  PLANNING 

general  maneuver 
PLANNING  AND 
OPTIMIZATION 
RENDEZVOUS  PLANNING 
MISSION  PLANNING 
TABLE 

49,500 

29,520 

H 

i 

TOTALS 

109,760 

50,030 

159,790 
— 

95321  Orbit  Trajectory  Computations 

The  orbit  trajectory  computations  software  is  responsible  for  generation 
of  current  trajectory  information  In  particular,  it 

9 Maintains  current  orbital  ephemerides  which  describe  Tug  vehicle 
trajectory  containing  periods  of  free-fhght  and/or  powered 
flight. 

• Maintains  detailed  information  for  currently  planned  maneuvers 

• Computes  numerous  parameters  for  definition  and  evaluation  of 
predicted  Tug  trajectories 

The  software  to  accomplish  the  above  functions  is  discussed  in  the  following 
paragraphs  A functional  description  of  the  trajectory  computation  process 
is  shown  in  Figure  9 5 3-6 

Ephemens  Generation  and  Control 

The  ephemens  generation  and  control  software  generates,  maintains,  and 
references  ephemerides  for  the  Tug  vehicle,  the  Space  Shuttle,  and  the 
target  vehicle  The  ephemerides  provide  rapid  access  and/or  computation 
of  trajectory  dependent  data  for  mission  planning  and  real-time  flight 
monitoring 

The  ephemerides  are  of  two  types,  live  or  static  A "LIVE"  ephemens  des- 
cribes the  current  trajectory  of  a vehicle.  It  is  considered  live  because  the 
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Figure  9 5 3-6.  Trajectory  Computation  Process 

trajectory  is  computed  and  output  on  trajectory  evaluation  displays  for 
monitoring  purposes  In  addition,  the  live  ephemeris  is  advanced  as  current 
time  processes,  A "STATIC"  ephemens  describes  the  predicted  trajectory  from 
an  anchor  vector  whose  time  is  anywhere  within  the  mission  profile  The 
anchor  vector  is  either  specified  by  the  user  or  defaults  to  the  times  of  the 
last  anchor  vector  specified  The  "STATIC"  ephemeris,  therefore,  does  not 
advance  with  time  but  instead  remains  fixed  at  the  defined  base  state 

Ephemerides  have  the  following  additional  characteristics 

• Each  can  contain  periods  of  free  flight  and/or  powered 
flight 

• Density  of  each  ephemeris  is  three  minutes  for  free  flight 
periods  and  10  seconds  of  powered  flight  periods. 

The  ephemeris  generation  and  control  software  is  subdivided  into  three 
major  areas  (1)  control  logic,  C2)  ephemeris  generation  logic,  and 
(3)  display  requirements  These  areas  are  addressed  in  the  following  para- 
graphs 
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Control  Logic  - The  control  logic  performs  initialization  and  super- 
visory functions  necessary  in  maintaining  and  referencing  vehicle  ephemendes 
There  are  five  categories  of  processing  within  the  control  logic  (1) 
input  processing,  (2)  anchor  vector  table  maintenance,  (3)  vector  routines, 
(4)  trajectory  update  supervision,  and  (5)  miscellaneous  vector  processing 
The  following  steps  are  executed  in  performing  these  functions 

• Vector  for  a specified  vehicle  ephemeris  is  entered  via 
manual  entry  device 

• Vector  is  stored  in  anchor  vector  table 

t Ephemeris  vector  is  generated 

• A trajectory  update  is  performed  utilizing  new  anchor 
vector 

• Miscellaneous  vector  routines  are  used  to  perform  trajectory 
computations 

Ephemeris  Generation  - The  ephemeris  generation  software  performs  the  actual 
generation  of  a vehicle  ephemeris  and  updates  the  necessary  tables  to  reflect 
the  current  trajectory  Since  each  ephemeris  can  contain  periods  of  free- 
flight  and  powered  flight,  the  software  updates  the  ephemeris  table  with 
both  types  of  vectors 

Display  Requirements  - This  portion  of  the  ephemeris  generation  and  control 
software  provides  the  capability  to  display  ephemeris  associated  data  to 
flight  controller  personnel  These  displays  contain  the  following  types 
of  data 


• Vehicle  state  vector  at  specified  time 

• Earth-referenced  position  at  specified  time 

• Arrival  time  and  orientation  at  specified  point 

• Current  vehicle  state  vector 

e Time-to-go  to  specified  position 

Station  Contacts 


The  station  contacts  software  determines  when  the  Tug  vehicle  and  radar 
ground  stations  are  in  contact  with  each  other,  displays  this  data,  and 
informs  the  remote  station  of  upcoming  contact  periods  To  accomplish 
these  functions,  the  software  has  been  divided  into  the  following  areas 

• Station  contact  generation 

t Station  contact  displays 

t Remote  site  acquisition 
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Station  Contact  Generation  - The  programs  in  this  unit  generate  orbit  station 
contact  information  based  on  specified  ephemens.  The  mathematical  models 
required  to  determine  horizon  crossing  times,  terrain  masking  effects,  and 
keyhole  loss  of  signal  times  are  maintained  When  given  site  definitions  and 
ephemens  data,  the  program  will  generate  a chronological  list  of  station 
contacts. 

Station  Contact  Displays  - The  station  contact  displays  software  produces 
information  about  present  and  future  station  acquisition  and  parameters 
associated  with  those  contacts. 

Remote  Site  Acquisition  - The  transmission  of  acquisition  messages  to  the  re- 
mote tracking  stations  is  the  function  of  this  software.  Information  contained 
within  the  messages  is  as  follows 

• Slant  range,  receiver  frequency,  transmitter  frequency, 
bias  doppler,  and  one  way  doppler  to  S-Band  stations 

• Pointing  data  for  tropospheric  refraction 
95322  Mission  Planning 

The  mission  planning  software  will  provide  the  capability,  under  control  of 
mission  controller  entry,  to  produce  displays  for  use  m evaluating  the  current 
trajectory's  ability  to  satisfy  mission  objectives  In  addition,  the  ability 
to  produce  and  evaluate  alternate  flight  plans  will  be  provided 

The  mission  planning  software  is  composed  of  two  basic  elements  - the  mission 
planning  table  and  the  mission  planner. 

Mission  Planning  Table  - The  mission  planning  table  is  the  focal  point  of  the 
trajectory  computation  software  and  contains  the  following  information 

• Ephemens  data 

• Maneuver  data 

• Vehicle  attitude  data 

• Sequencing  data 

• Station  contact  data 

• Rendezvous  plan 

The  initial  mission  planning  table  is  created  prior  to  the  Tug  mission  to 
satisfy  the  objectives  of  a nominal  mission.  During  the  mission,  the  table 
can  be  updated  to  reflect  the  actual  mission  profile  and  can  also  be  used  for 
contingency  planning  purposes 

Mission  Planner  Program  - The  mission  planner  program  will  be  utilized  in  the 
evaluation  of  the  Tug  trajectory  and  in  the  generation  of  new  flight  plans 
resulting  from  contingency  situations.  The  mission  planner  will  function  in 


9-41 


an  interactive  environment  with  the  flight  controller  Displays  will  be 
produced  for  evaluation  by  the  flight  controller  Selection  of  a new  flight 
plan  will  result  in  the  new  trajectory's  description  being  used  to  generate 
new  ephemeris  and  mission  planning  tables  A functional  diagram  of  the  mission 
planner  is  shown  in  Figure  9 5 3-7 

The  principal  use  of  the  mission  planner  will  be  m contingency  planning 

Contingency  Planning  - The  mission  planner  will  use  the  mission  planning  table 
to  support  the  need  for  contingency  planning  in  real-time  Flight  controllers 
will  be  able  to  introduce  general  data  for  evaluation  and  the  mission  planner 
will 

• Determine  the  effects  that  a given  incremental  velocity  applied  along 
a specific  axis  will  have  on  the  mission  profile 

• Determine  the  desired  maneuver  required  to  change  from  the  present 
orbit  to  a specified  orbit 

Information  provided  for  contingency  planning  will  be  entered  into  the  mission 
planning  table  only  if  the  flight  controller  selects  the  new  plan  for 
implementation 

9533  Control  Software 

The  Control  Software  provides  the  capabilities  to  control  overall  software 
execution  and  interface  with  Flight  Support  Facilities  A diagram  of  the 
functioning  of  the  Control  Software  is  shown  in  Figure  9 5.3-8 


MED  INPUT 
(CONTINGENCY) 


MED  INPUT 
(NEW  PLAN) 


Figure  9 5 3-7  Mission  Planner 
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Figure  9 5.3-8 . TOC  Control  Software 


95331  Executive 


The  executive  program  functions  as  the  supervisor  of  the  application  software 
within  the  central  computer  and  controls  and  sequences  all  input/output 
activity  In  addition,  the  software  within  the  executive  will  provide  the 
capability  to  recover  from  component  failures  within  the  control  center 
without  degrading  system  integrity  The  subelements  which  comprise  the 
executive  and  the  size  of  the  executive  software  are  shown  in  Table  9 5 3-5 

Table  9.5  3-5.  Executive  Software  Summary 


FUNCTION 

NO  OF 

INSTRUCTION 

WORDS 

NO  OF 

DATA 

WORDS 

TOTAL 

TASK  MANAGEMENT 

74,127 

5,321 

72,448 

APPLICATION  TASK  CONTROL 
INITIALIZATION 
ERROR  RECOVERY 
QUEUE  MANAGEMENT 
MASTER  SCHEDULER 
OPERATING  SYSTEM  UTILITIES 

DATA  MANAGEMENT 

74,281 

7,683 

81,964 

RESOURCE  MANAGEMENT 
DATA  LOGGING 
STATISTICS  GATHERING 
AUXILIARY  STORAGE 
! OPERATING  SYSTEM  UTILITIES 

INPUT/OUTPUT  MANAGEMENT 

29,492 

4,369 

33,861 

I/O  CONTROL 
INTERRUPT  HANDLING 
OPERATING  SYSTEM  UTILITIES 

SYSTEM  INITIALIZATION 

33,000 

11,931 

44,931 

TOTALS 

210,900 

29,304 

240,204 

The  executive  program  is  designed  to 

• Minimize  the  application  system  hardware  dependence 

• Ensure  fast  response  to  system  activity 

« Provide  simplicity  to  application  program  development 

• Provide  the  support  to  application  software  in  handling 
large  amounts  of  real-time  data 

• Provide  a flexible  base  for  future  expansion 

The  major  functions  provided  for  application  software  are  task  management, 
data  management,  input/output  management,  system  initialization  and  simu- 
lation support  These  major  functions  are  discussed  in  the  following 
paragraphs.  Reference  should  be  made  to  Figure  9.5  3-8  to  follow  the 
interfacing  of  the  subelements  discussed  following 
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Task  Management  - The  task  management  capability  of  the  executive  is  built  upon 
the  independent  task  concept  In  this  concept,  an  independent  task  is  able  to 
receive  work  at  all  times  regardless  of  the  input  data  rate.  When  data  is 
received  by  the  system  for  a task,  it  is  sent  in  the  form  of  a request  Each 
request  has  its  own  priority  which  in  turn  becomes  the  priority  of  the  task 
If  a task  is  processing  a request  and  a new  request  is  received  from  the  task, 
the  new  request  is  held  according  to  its  priority  and  processed  upon  completion 
of  the  request  in  progress 

Each  task  is  assigned  an  area  in  main  storage  called  a resource  table  This 
is  a private  area  that  can  be  used  by  the  program  running  under  the  task  In 
addition,  each  task  is  assigned  a unique  protect  key  which  protects  it  from 
all  programs  controlled  by  other  tasks 

Master  Scheduler  - The  master  scheduler  examines  all  input  data  and  acts 
as  an  interface  between  the  hardware  interrupt  servicing  function  and  the 
task  management  function  When  the  master  scheduler  receives  an  input 
message,  it  compares  the  message  with  the  current  data  definitions  If  a 
compare  exists,  the  message  is  routed  to  the  task  which  will  process  it  If 
no  compare  exists,  the  message  is  discarded.  The  master  scheduler  can  also 
accumulate  a number  of  messages  for  the  same  task  and  generate  a request  for 
the  task  after  the  specified  number  of  messages  have  been  received  In  this 
case,  all  the  accumulated  messages  will  be  sent  to  the  task  as  one'request 

Within  the  Control  Center,  work  requests  will  also  be  generated  according  to 
elapsed  time.  For  example,  a task  may  be  created  to  control  a load  module 
which  updates  the  position  of  the  vehicle  every  second  The  only  data 
necessary  to  perform  this  operation  is  the  previous  position  and  the  orbital 
parameters  Since  this  data  exists  within  the  software  system,  no  external 
signal  will  occur  to  request  execution  of  the  task.  In  a case  such  as  this, 
the  request  will  be  generated  through  a timer  interrupt  under  control  of  the 
software  This  technique  for  task  requests  is  known  as  time  routing 

Time  Routing  - Time  routing  is  used  within  the  Control  Center  software  to 
generate  work  requests  on  specified  time  intervals  It  functions  as  the 
interface  between  the  time  management  function  of  the  executive  and  the  task 
management  function.  When  an  application  program  requests  a series  of  time 
dependent  activations,  the  time  routing  program  sends  the  request  to  time 
managment  specifying  the  time  when  the  next  request  should  be  generated 
When  the  timer  interrupt  associated  with  the  request  is  received,  time  manage- 
ment will  call  the  time  routing  function  which,  in  turn,  will  call  the 
required  task 

Queue  Management  - As  mentioned  previously,  if  a task  is  processing  a work 
request,  all  other  requests  for  that  task  must  be  held  by  the  system  until 
the  task  is  available  for  further  processing  To  support  this  operation, 
the  executive  must  build  and  maintain  a queue  of  work  requests  waiting  to 
be  processed  by  each  active  task  Information  concerning  each  request  is 
held  in  a real-time  queue  element 

Each  active  task  will  be  processing  one  work  request  and  that  request  is 
represented  by  the  active  queue  element  All  other  requests  for  the  tasks 
will  be  placed  m the  queue  of  ‘waiting1  elements  Requests  from  the 
‘waiting1  elements  are  ordered  according  to  priority,  in  the  case  of  equal 
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priority,  first-in  first-out  (FIFO)  is  the  order  of  processing  When  the 
task  completes,  the  request  of  high  priority  is  made  active  and  passed  to 
the  task  for  processing  If  no  'waiting*  requests  exist,  the  task  becomes 
dormant  awaiting  new  data  for  processing 

If  queue  management  is  not  provided,  the  queue  elements  can  accumulate 
indefinitely  unless  the  tasks  can  process  their  work  requests  faster  than 
they  are  generated  Queue  management  provides  the  capability  to  control 
requests  by  limiting  their  number  It  can  also  be  used  to  control  system 
load  by  not  giving  requests  to  a task  until  other  tasks  are  complete 

Time  Management  - The  computer  to  be  utilized  within  the  Tug  Control  Center 
will  be  equipped  with  a special  high  resolution  GMT  clock  and  interval  timer 
To  provide  support  for  these  timer  devices,  a time  management  supervisor  will 
be  required  within  the  executive  The  supervisor  maintains  system  time  and 
controls  the  setting  and  interrupt  handling  functions  resulting  from  the 
timer  hardware 

System  Recovery  - It  is  of  prime  importance  that  the  software  continue  to 
function  in  the  presence  of  errors  or  failure  conditions  Three  areas  of 
software  are  required  to  address  switchover,  high-speed  restart,  and 
error  recovery 

For  system  reliability  considerations,  a backup  mam  computer  system  will 
exist  within  the  ground  control  center  The  ability  to  select  the  backup 
computer  system  without  interruption  to  the  input/output  processing  of 
real-time  data  or  degradation  of  mission  output  will  be  performed  within 
the  executive  program 

In  the  event  of  computer  failure,  the  backup  computer  system  must  be  brought 
online  within  a minimum  specified  time  interval  An  initial  load  program  will 
exist  within  the  executive  to  transfer  all  required  data  from  the  operational 
system  to  the  selected  backup  system 

The  error  recovery  function  of  the  executive  pertains  to  errors  resulting 
from  program  checks,  hardware  malfunctions,  or  abnormal  conditions  arising 
within  the  software  system  itself  In  effect,  error  recovery  capability  is 
restricted  to  those  errors  recognizable  within  the  software  for  which  software 
action  can  be  taken  The  error  recovery  programs  will  print  appropriate 
messages  and  recommendations  regarding  system  status 

Operating  System  Utilities  - The  executive  program  for  the  Tug  Control  Center 
will  be  built  around  the  capabilities  of  the  operating  system  provided  with 
the  computer  This  approach  will  allow  utilization  of  existing  system  soft- 
ware and  will  provide  a standard  base  for  development  of  application  software 
In  addition,  the  utilization  of  the  computer's  operating  system  will  allow 
one  control  center  computer  to  be  used  for  normal  job  processing  when  not 
being  used  for  real-time  mission  support 

Input/Output  Management 

Because  of  the  real-time  nature  of  input/output  processing,  special  techniques 
must  be  provided  to  handle  this  activity  efficiently  and  rapidly  These 
techniques  are  included  in  the  following  functional  areas  of  the  input/output 
management  software 
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• Real-time  access  method 

• Real-time  interrupt  servicer  and  start-stop  input  routing 

• Digital /TV  display  control 

• Shared  device  support 

Real-Time  Access  Method  - The  real-time  access  method  performs  device  dependent 
data  manipulation  and  output  messages  to  special  real-time  devices  within  the 
Tug  Control  Center  It  also  is  used  to  control  the  reading  of  information  from 
the  display  hardware  used  by  flight  controllers  Output  to  all  display  hard- 
ware is  also  controlled  by  the  real-time  access  method 

Real-Time  Interrupt  Servicer  and  Start/Stop  Input  - The  real-time  interrupt 
servicer  and  start/stop  routines  provide  control  over  the  input  from  real-time 
input  devices  within  the  control  center.  The  servicer  passes  the  request 
information  to  the  master  scheduler  for  use  in  scheduling  the  execution  of  the 
appropriate  task  The  start/stop  input  routine  controls  the  initiation  and 
transfer  of  data  from  the  input  device  and  can  stop  the  transfer  in  the  event 
of  failure 

Digital/TV  Display  Control  - The  digital/TV  display  control  program  provides 
support  to  the  digital  TV  stations  within  the  ground  control  center  It  ser- 
vices all  digital  TV  display  requests,  maintains  information  regarding  which 
displays  are  currently  being  viewed  and  the  consoles  viewing  them,  controls 
the  dynamic  allocation  of  the  digital /TV  channels,  and  generates  the  request 
for  tasks  which  supply  data  for  use  in  updating  displays 

Data  Management 

The  data  management  portion  of  the  ground  control  center  executive  performs 
the  functions  of* 

• Data  logging 

• Data  table  maintenance 

• Auxiliary  storage  control 

• Background  utilities 

The  functional  discussions  of  these  elements  are  contained  in  the  following 
paragraphs 

Data  Logging  - In  a real-time  environment,  it  is  essential  that  a technique 
be  provided  which  saves  the  data  received,  transmitted,  and  processed  by  the 
system  Within  the  control  center,  alT  such  data  is  recorded  on  magnetic 
tape  In  addition  to  system  inputs/outputs,  application  program  data  can  be 
recorded  for  program  checkout  purposes 

Data  Table  Maintenance  - Because  of  the  large  amounts  of  data  which  must  be 
accessed  and  manipulated  during  support  of  a Tug  mission,  a series  of  control 
programs  will  be  utilized  to  support  data  table  handling. 

Data  tables  are  blocks  or  arrays  of  data  maintained  on  direct  access  devices 
Through  use  of  data  table  control  software,  tables  can  be  'logged'  to  ensure 
data  integrity  and  consistency  during  a read  operation.  This  will  delay  any 
tasks  attempting  to  write  into  the  table  until  the  data  has  been  'unlocked'. 
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Each  data  table  is  identified  by  a name  field  and  is  defined  by  its  block  size 
and  number  of  blocks  A data  table  generation  program  uses  these  parameters 
in  allocating  space  for  each  table  and  providing  the  controls  required  to 
access  it 

Auxiliary  Storage  Control  - Because  the  overall  software  size  for  the  control 
center  will  exceed  the  capacity  of  the  computer's  main  memory,  direct  access 
devices  will  be  used  to  store  all  programs  not  required  to  reside  in  memory 
at  all  times  The  retrieval  of  these  programs  from  auxiliary  storage  in  real- 
time and  the  dynamic  loading  into  mam  memory  are  functions  performed  by  the 
auxuiliary  storage  control  software 

Background  Utilities  - Numerous  capabilities  have  been  included  in  the 
executive  for  use  m background  operations  which  can  be  initiated  or  terminated 
by  console  operation  These  background  utilities  execute  asynchronously  with 
normal  operation  and  provide  the  following  capabilities 

9 Dump  auxiliary  memory  to  tape 

• Restore  auxiliary  memory  from  tape 

• Clear  auxiliary  storage  device 

• Copy  a tape 

• Compare  tapes 

t Print  magnetic  tape 

Statistics  Gathering  System  - The  statistics  gathering  system  provides  timing 
information  and  execution  frequency  statistics  useful  in  accessing  overall 
system  performance  Example  of  the  types  of  statistics  are  given  below 

• CPU  Performance  - shows  the  amount  of  CPU  utilization, 
the  time  spent  waiting  on  I/O,  or  time  spent  in  gathering 
statistics 

• Load  Module  Performance  - shows  the  execution  frequency, 
average  execution  time,  percent  of  CPU  utilization,  and 
number  of  requests  for  each  task 

t Task  Performance  - shows  the  number  of  task  executions 
per  specified  time  interval  and  the  execution  time  for 
task 

• Executive  Performance  - shows  the  percent  of  CPU  utilization 
spent  in  performing  executive  functions 

System  Initialization 

Prior  to  initiation  of  the  application  software  to  support  a Tug  mission, 
the  executive  will  perform  the  necessary  diagnostics  on  system  hardware, 
configure  the  hardware  in  accordance  with  input  specification,  and  initialize 
the  application  software  to  accept  task  requests 

The  system  initialization  software  will  reside  on  auxiliary  storage  devices 
and  will  be  loaded  into  mam  memory  under  control  of  the  computer's  operating 
system  The  initialization  software  then  controls  the  loading  of  remaining 
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software  into  mam  memory  and  will  pass  control  to  the  task  management 
function  when  all  initialization  tasks  have  been  completed  The  main  memory 
utilized  by  system  initialization  then  becomes  available  for  system  use 

Simulation  Support 

To  assist  in  development  of  the  application  software,  the  executive  program 
has  two  features  which  provide  significant  testing  capability  These  features, 
discussed  below,  are  simulated  input  control  (SIC)  and  fast  time. 

Fast  Time  - Fast  time  is  a capability  of  the  executive  to  stop  the  time 
reference  if  no  software  activity  is  scheduled  In  this  way,  many  hours  of 

computer  time  and  programmer  time  can  be  saved  Using  this  capability,  the 

input  messages  are  processed  as  rapidly  as  the  tasks  can  be  run. 

Simulated  Input  Control  (SIC)  - Simulated  input  control  provides  the  cap- 
ability to  send  simulated  input  data  into  the  application  software  for  test 
purposes  This  input  data  can  be  in  the  form  of  cards  or  tape  or  both.  All 
data  has  the  time  of  receipt  ’associated  with  each  message  and  SIC  routes 
each  data  message  to  the  master  scheduler  for  scheduling  of  the  required  task. 
For  convenience,  SIC  will  allow  data  log  magnetic  tapes  to  be  used  as  source 
for  simulated  input.  In  this  manner,  actual  data  obtained  from  previous 
flights  or  simulations  can  be  used  as  a test  bed  for  software  change  veri- 
fication. 

9 5 3.3.2  Control  Center  Support  Software 

As  was  discussed  previously,  the  executive  program  provides  the  input/output 
capability  to  interface  with  the  hardware  devices  within  the  control  center 
In  addition  to  the  software  existing  for  input/output,  significant  software 
is  required  to  format  data  properly  for  output,  to  provide  the  data  requested, 
and  to  maintain  the  data  base  required  for  display  purposes.  A functional 
description  of  the  control  center  support  software's  relationship  to  the 
executive  and  hardware  external  to  the  computer  system  is  shown  in  Figure 
9.5  3-8  Sizing  data  is  shown  m Table  9 5.3-6 


Table  9.5.3-B.  Control  Room /Display  Management 


FUNCTION 

NO.  OF 

INSTRUCTION 

WORDS 

NO.  OF 

DATA 

WORDS 

TOTAL 

DISPLAY  DEVICE  INPUT  SERVICING 

1,904 

400 

2,304 

DISPLAY  DEVICE  OUTPUT 

10,786 

2,840 

13,626 

TOTALS 

12,690 

3,240 

15,930 

9 5.3.4  Simulation  System  Software 

In  the  development  and  qualification  of  the  control  center,  data  from  external 
sources  such  as  remote  sites,  Tug  vehicle,  etc,,  will  not  be  available  on  a 
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continuing  basis  In  addition,  certain  hardware  systems  within  the  control 
center  may  not  be  available  when  needed  to  support  testing  To  provide  an 
environment  to  assure  the  capability  to  perform  testing  at  all  times,  deve- 
lopment of  a simulation  capability  will  be  required  This  simulation  cap- 
ability will  be  performed  through  software  modelling  of  the  control  center 
environment  The  simulator  will  provide  simulated  real-time  inputs,  under 
control  of  simulation  personnel,  to  test  both  the  nominal  and  contingency 
capabilities  of  the  control  center 

Simulations  have  been  utilized  m both  the  Mission  Control  Room  at  JSC  and 
at  the  Deep-Space  Control  Center  at  JPL  with  significant  results  For  the 
Tug  Control  Center,  the  simulation  system  will  be  used  to  address  testing 
requirements  associated  with  hardware  checkout,  software  development,  pro- 
cedural verification,  and  ground  controller  training 

The  subelements  which  comprise  the  simulation  system  are  shown,  with 
corresponding  sizing  information,  in  Table  9 5 3-7 


Table  9 5 3-7  Simulation  System  Size 


FUNCTION 

NO  OF 

INSTRUCTION 

WORDS 

NO  OF 

DATA 

WORDS 

TOTAL 

TUG  VEHICLE  SIMULATION 

56,250 

16,560 

72,810 

GROUND  STATION  SIMULATION 

49,500 

7,500 

57,000 

TCC  SUBSYSTEMS  SIMULATION 
DISPLAYS 

10,800 

19,800 

21,600 

MED  ENTRIES 

13,500 

5,400 

18,900 

SIMULATED  INPUT  CONTROL 

6,750 

6,780 

13,530 

TOTALS 

136,800 

47,040 

183,840 

9 5 3 4 1 Simulation  Descnption/Qperation 

The  overall  functional  description  of  the  simulation  system  and  its  re- 
lationships with  the  operational  software  and  hardware  of  the  control  center 
are  shown  in  Figure  9 5.3-9  The  simulation  system  contains  models  of  the 
following  operational  components* 

• Tug  vehicle 

• Ground  station 

• Subsystems  within  the  control  center,  such  as  displays, 

consoles,  and  panels 

To  provide  a near  real-time  environment,  the  simulation  system  software  will 
be  executed  within  the  backup  central  computer  system  The  primary  central 
computer  will  contain  the  operational  software  of  the  control  center  The 
simulation  software  will  perform  all  modelling,  as  requested  by  the  simu- 
lation controller,  and  provide  inputs  to  the  operational  software  Outputs 
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of  the  operational  software  will  be  directed  to  the  control  center  hardware 
or  simulated  models  Uplink  commands  will  be  routed  to  the  simulation  system 
rather  than  to  remote  sites  Through  this  operation,  a closed-loop  simulation 
is  achieved  which  will  provide  significant  flexibility  m the  overall  testing 
plan  for  the  control  center 

The  elements  of  the  simulation  system  are  discussed  in  the  following  para- 
graphs 

Tug  Vehicle  Model  - The  model  of  the  Tug  vehicle  is  a detailed  mathematical 
model  which  includes  the  following  onboard  systems 

t Onboard  computer  (includes  onboard  computer  software) 

• Guidance 

• Telemetry 

• Stabilization  and  control 

• Reaction  control 

t Propulsion 

• Sequential  events 

• Attitude  sensors 

• Uplink  command 

• Power 

• Payload 

Ground  Station  Model  - The  ground  station  model  will  accept  as  input  the 
telemetry  data  generated  by  the  vehicle  module  and  will  generate  telemetry 
data  in  the  format  acceptable  to  the  Tug  Control  Center  software 

Control  Center  Hardware  - Since  a signficant  portion  of  the  simulation  will 
be  controlled  from  flight  consoles  and  manual  entry  device  inputs,  this 
control  center  hardware  will  be  modelled  within  the  simulation  system 

For  MED  inputs,  tables  of  input  data  to  be  executed  as  a function  of  mission 
time  will  be  established  prior  to  the  mission  simulation  As  the  mission  is 
simulated,  these  inputs  will  be  issued  at  the  appropriate  time  Each  issu- 
ance will  be  logged  for  post-simulation  analysis,  and,  in  addition,  tests 
will  be  conducted,  during  the  simulation,  on  response  of  the  operational 
software  to  the  stimuli  issued  through  the  MED  simulation 

Display  simulation  will  test  the  capability  of  the  operational  software  to 
properly  respond  to  display  requests  and  display  properly  formatted  data 
The  display  data  will  be  logged  for  post-simulation  analysis  Correlation 
between  the  data  generated  by  the  simulation  and  that  calculated  and 
displayed  will  be  accomplished  during  the  simulation  and  logged  for  analysis 

Simulated  Input  Control  - The  simulated  input  control,  although  a subset 
of  the  simulation  system,  is  a 'stand  alone'  simulation  tool  for  selective 
entry  of  data  into  the  operational  software  This  capability  provides  a 
means  of  performing  software  checkout  without  the  overall  simulation  system 
being  involved.  The  input  is  largely  manual  and  provides  a tightly  controlled 
testing  environment 
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9 5 3.4.2  Simulation  System  Utilization 

As  was  stated  previously,  the  prime  uses  of  the  simulation  system  are 

• Hardware  checkout 

o Software  development 

t Procedural  verification 

• Flight  controller  training 

Hardware  Checkout  - Through  use  of  the  hardware  simulation  capability,  a data 
base  can  be  provided  for  comparison  between  actual  hardware  and  modeling  test 
cases  Replacing  software  models  with  actual  hardware  also  provides  veri- 
fication of  system  interfaces  prior  to  overall  system  testing. 

Software  Development  - The  simulation  system  will  be  utilized  to  provide 
i nputs , during  software  development,  for  program  checkout  purposes.  Because 
of  the  input  control  features  of  the  simulation  system,  predictable  test 
cases  can  be  generated  and  conducted  This  use  of  the  simulation  system  will 
provide  a base  for  systematically  testing  the  operational  software  in  a realis- 
tic environment  and  will  allow  testing  to  proceed  at  the  overall  system  level 
before  requiring  the  participation  of  outside  activities 

Procedure  Verification  - Prior  to  each  Tug  mission,  a flight  plan  will  be 
generated  This  flight  plan  will  detail  the  procedures  to  be  followed  to  ensure 
that  the  Tug  mission  achieves  all  objectives.  The  simulation  system  will  pro- 
vide the  test  bed  to  verify  that  the  procedures  are  correct. 

Flight  Controller  Training  - Flight  controllers  must  be  trained  to  handle 
all  contingency  situations  In  view  of  the  criticality  of  flight  controller 
expertise,  a thorough  training  program  prior  to  the  actual  mission  must  be 
provided. 

The  simulation  system  is  ideally  suited  to  provide  the  training  needed  by 
flight  controllers  The  simulation  system  in  conjunction  with  the  control 
center  software  can  reproduce  all  nominal  events  and  non-norm nal  conting- 
encies which  may  occur  during  a mission  The  active  participation  of  flight 
controllers  m overall  system  simulation  will  ensure  that  the  controller  is 
thoroughly  familiar  with  available  mission  support  tools,  data  and  will 
provide  training  m a real-time  environment 

9535  Software  Summary 

This  section  of  the  Tug  study  report  has  identified  the  functional  software 
requirements  which  must  be  satisfied  in  order  to  control  the  Tug  vehicle 
from  a control  center.  The  overall  sue  of  the  software  has  also  been 
addressed  and  is  summarized  in  Table  9 5.3-8. 

The  primary  emphasis  has  been  placed  on  ensuring  that  all  the  functional  require- 
ments have  been  addressed.  The  software  size,  which  has  been  developed,  is 
based  on  a study  of  similar  software  at  the  JSC-RTCC  and  JPL-DSC.  As  can  be 
seen  in  Figure  9 5.3-10,  the  Tug  software  size  is  less  than  previous  ground 
control  center  software  for  other  space  programs,  however,  as  the  Tug  control 
center  requirements  are  more  clearly  defined,  the  software  may  grow. 
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Table  9 5 3-8  Tug  Control  Center  Software  Summary  Size 


FUNCTION 

NO  OF 

INSTRUCTION 

WORDS 

NO  OF 

DATA 

WORDS 

TOTAL 

DOWNLINK  PROCESSING 

68,190 

12,540 

80,730 

UPLINK  PROCESSING 

32,980 

14,640 

47,620 

MISSION  PROFILE 

109,760 

50,030 

159,790 

EXECUTIVE  SYSTEM 

210,900 

29,304 

240,204 

CONTROL  CENTER  SUPPORT 

12,690 

3,240 

15,930 

SIMULATION  SYSTEM 

136,800 

47,040 

183,840 

TOTALS 

571,320 

156,794 

728,114  j 

954  AIRBORNE  OPERATIONS  SUPPORT  SOFTWARE 

The  Flight  Software  requirements  for  a Level  II  Tug  vehicle  are  estimated,  based 
upon  the  anticipated  share  of  the  mission  operations  decision  requirements 
Four  baseline  flight  programs  have  been  postulated,  and  the  specific  mission 
implementation  is  to  be  a modular  adaptation  of  one  of  the  baseline  programs 
The  following  paragraphs  discuss  the  general  approach  to  the  Tug  Flight  Program. 

The  flight  program  is  an  integral  part  of  (1)  the  guidance  and  control  sys- 
tem comprising  the  central  computer,  data  bus,  IMU,  star  tracker,  sun  sensor. 
Landmark  Tracker,  Rate  gyros  and  the  flight  control  electronics,  and  (2)  the  Tug 
sequencing  system  comprising  the  discrete  input,  discrete  output,  and  interrupt 
processing  of  the  central  computer 

The  integration  of  these  systems  is  accomplished  through  the  flight  program 
It  provides  a flexible  mechanism  by  which  the  system  functional  and  detailed 
specifications  may  be  altered,  within  wide  limits,  to  accomplish  a wide  variety 
of  missions  without  changes  to  the  vehicle  hardware 

Although  specific  requirements  will  vary  with  mission  phase,  the  flight  program 
is  required  to  provide  for  the  following  recurring  functions 

• Navigation 

• Guidance 

• Attitude  Control 

• Sequencing 

• Tel emetry 

• Programmed  backups  to  specific  hardware  functions 

• Command  processing 

• IMU  processing 
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9.5.4. 1 Non-Recurring  Functions 

The  one-time  targeting  requirement  is  performed  at  approximately  two  hours 
prior  to  shuttle  liftoff.  The  targeting  parameters  are  loaded  via  the  LPS 
with  a backup  load  performed  by  ground  DCS  command  if  required.  The  variable 
target  optimization  capability  provides  data  loads  to  the  flight  program 
assuring  optimum  performance  dependent  data. 

9. 5.4.2  Recurring  Functions 

Of  the  recurring  functions  listed  above,  command  processing  is  required  for  the 
one-time  targeting  requirement  and  during  the  orbital  mission  phase.  The 
remaining  functions  are  required  during  both  the  boost  and  coast  phases 
although  specific  requirements  and  rates  of  computation  may  vary  from  the  boost 
to  the  coast  phases.  Each  requirement  is  discussed  separately  except  for 
navigation  and  guidance  which  are  more  closely  tied  together  than  the  other 
requirements.  In  addition,  the  guidance  law  and  navigation  scheme  requirements 
are  significantly  different  during  the  boost  and  coast  phases.  Therefore, 
these  two  requirements  are  combined  in  the  discussion  and  this  particular 
discussion  is  broken  into  boost  and  coast  mission  phases. 

The  following  definitions  of  navigation,  guidance  and  control  apply  in  this 
document. 
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Navigation:  The  calculation  of  vehicle  position 

and  velocity  at  any  time  with  respect 
to  a specified  reference  frame. 

Guidance:  The  computation,  according  to  a specified 

law,  of  instantaneous  vehicle  attitude, 
with  respect  to  a specified  reference 
frame,  necessary  to  achieve  a specified 
state  vector  and/or  vehicle  attitude  at 
some  future  time. 

Control:  The  computation,  according  to  a specified 

law,  of  the  vehicle  commands  necessary  to 
achieve  the  required  instantaneous  vehicle 
attitude  and  operation  of  the  proper  hard- 
ware to  position  the  vehicle. 

9. 5. 4. 2.1  Boost  Navigation  and  Guidance 

Since  variations  in  acceleration  are  large  during  boost,  the  computation  rate 
for  navigation  must  be  higher  than  during  coast.  In  determining  position  and 
velocity  relative  to  the  desired  reference  frame,  gravitational  effects  are 
computed  as  part  of  the  navigation  scheme  since  the  sensors  cannot  measure 
gravitational  acceleration.  A mathematical  model  of  the  earth's  gravitational 
field,  which  was  empirically  derived  from  satellite  measurements,  will  be  used 
in  the  gravitational  computations.  Position  and  velocity  in  the  desired  ref- 
erence frame  are  obtained  by  differencing  the  integrated  measured  and  gravi- 
tational accelerations.  The  computation  rate,  or  integration  interval  will  be 
variable.  With  these  rates,  and  the  smoothed  acceleration  function,  a simple 
trapezoidal  integration  routine  yields  sufficient  accuracy.  A single  naviga- 
tion scheme  is  adequate  through  the  boost  phase. 

In  order  to  achieve  the  correct  orbital  inclination  and  longitude  of  descend- 
ing node,  active  guidance  is  required  in  both  the  pitch  and  yaw  planes.  Com- 
pensation in  the  guidance  law  is  required  for  abrupt  transients  in  vehicle 
performance  and  for  subtle  off-nominal  vehicle  characteristics  such  as  center 
of  gravity  offsets.  In  general,  active  guidance  laws,  including  IGM,  tend  to 
become  unstable  as  the  end  conditions  are  approached.  In  order  to  maintain  a 
stable  vehicle  at  cutoff,  certain  of  the  guidance  constraints  will  be  dropped 
shortly  before  cutoff.  In  particular,  the  position  constraints,  and  the  lat- 
eral and  vertical  position  rate  constraints  are  dropped  as  the  time-to-go 
approaches  zero.  The  component  velocity-to-be-gained  constraints  are  main- 
tained slightly  longer  and  the  commands  "frozen"  just  before  cutoff  to  ensure 
zero  angular  rates  and  a stable  vehicle.  The  time  of  cutoff  is  computed  as  a 
function  of  total  velocity-to-be-gained  and  the  cutoff  command  issued  to  the 
Tug  at  the  proper  time.  The  primary  constraints  on  the  orbit  are  inclination 
and  longitude  of  descending  node.  The  constrained  insertion  conditions  are 
radius,  path  angle,  and  velocity. 

9. 5. 4. 2. 2 Orbital  Navigation  and  Guidance 

The  Space  Tug  will  have  a self-contained  navigation  system  that  does  not  rely 
on  a dedicated  ground  support  system  for  earth  reference  data.  Earth  reference 
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data  is  acquired  continuously  and  processed  in  real  time  to  establish  Spacecraft 
position  and  velocity  Advances  in  digital  processing  hardware  and  software 
technology  and  earth  reference  sensors  have  made  autonomous  space  navigation 
systems  practicable. 

Accurate  navigation  of  the  Space  Tug  with  respect  to  the  earth  requires  sensing 
an  appropriate  earth  feature  in  some  portion  of  the  electromagnetic  spectrum 
Best  results  are  achieved  when  these  earth  features  and  the  performance  of 
the  electromagnetic  sensors  do  not  vary  with  seasonal,  diurnal,  and  atmospheric 
changes.  For  these  reasons  IBM  selected,  as  landmarks  of  known  position 
(latitude,  longitude,  and  altitude),  ground  radars  operating  in  the  2.5  to 
3 5 GHz  portion  of  the  electromagnetic  spectrum  Air  traffic  control,  defense 
early  warning,  coastal  search,  and  navigation  radars,  which  are  numerous  and 
distributed  worldwide,  satisfy  these  requirements  Since  there  are  more  than 
8000  such  radars  operating  24  hours/day,  radiation  m this  frequency  spectrum 
has  essentially  become  part  of  the  natural  environment 

System  Concept 

The  key  element  in  the  Space  Tug  autonomous  navigation  system  concept  is  the 
Interferometric  Landmark  Tracker  (ILT),  which  provides  accurate  angular  track- 
ing of  the  radar  landmarks  This  strapped-down  sensor,  composed  of  two 
orthogonal  phase  interferometers  operating  in  the  E/F  frequency  band,  provides 
a 120  degrees  field-of-view  and  permits  continuous  tracking  of  one  or  more 
radars  without  mechanical  or  electronic  scanning  This  performance  is 
independent  of  cloud  cover  or  time  of  day.  Figure  9 5 4-1  illustrates  the 
concept 

The  strapped-down  star  sensor  and  inertial  reference  unit,  in  combination, 
provide  an  attitude  determination  system  (ADS)  that  establishes  an  inertial 
attitude  reference  (+15  arc  seconds)  for  the  ILT  angular  measurement.  The 
necessary  computations  to  process  the  ADS  measurements  in  a 6-state  digital 
filter  and  navigation  measurements  in  a separate  16-state  digital  filter 
are  carried  out  in  the  on-board  digital  computer  A radar  altimeter,  operating 
only  over  the  seas  and  oceans,  is  included  to  limit  the  increase  of  position 
and  velocity  errors  during  long  periods  between  landmark  sightings  The 
altimeter  is  operated  for  1 second  every  10  minutes,  making  minimal  demands 
on  average  power  and  limiting  Space  Tug  detectability 

From  the  available  radars  within  the  frequency  band,  343  have  been  selected  as 
landmarks.  Wherever  possible,  these  are  distributed  to  provide  latitude  "chains" 
at  60  degrees,  45  degrees,  and  30  degrees  North  latitude  and  along  coastlines 
to  provide  longitude  bands.  The  343  radars  provide  redundant  landmarks  in  the 
northern  hemisphere,  that  is,  landmark  pairs  have  been  selected  such  that  two 
landmarks  are  simultaneously  within  the  field-of-view  of  the  ILT.  This  ensures 
landmark  availability  during  maintenance  or  other  down  time  of  any  radar  land- 
marks Because  of  the  scarcity  of  land,  and  consequently  radars,  in  the 
southern  hemisphere,  nearly  all  usable  radars  in  this  hemisphere  are  included 
in  the  landmark  table. 
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Figure  9 5 4-1.  Interferometric  Landmark  Tracker  Navigation  System  Concept 

The  landmarks  are  stored  in  the  computer  in  tabular  format,  organized  in 
latitude  bands  and  ordered  by  longitude  Landmark  latitude,  longitude, 
altitude,  and  frequency  are  stored  in  three  16-bit  words,  hence,  the  total 
landmark  table,  which  permits  navigation  over  all  orbital  inclinations,  requires 
1029  words  of  computer  memory.  (If  the  storage  were  optimized  on  a mission 
basis,  only  about  250  words  would  be  required)  Typically,  12  landmarks  per 
orbit  are  observed  in  low-altitude  polar  orbits 

Atti tude  Control 


The  primary  stabilization  loop  of  the  Tug  vehicle  is  the  attitude  control  loop 
which  is  closed  by  the  flight  program  in  the  central  computer  The  control  law 
requires  vehicle  turning  rates  and  accelerations  and  commanded  and  actual  ve- 
hicle attitudes,  with  respect  to  the  prescribed  reference  frame,  as  inputs 
Attitude  error  commands  are  issued  to  the  engine  actuators  through  the  vehicle 
control  system  to  effect  the  control  function 
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Limits  are  applied  to  the  rate  of  change  of  the  commanded  attitude,  the  commanded 
attitude  error  magnitude,  and  the  rate  at  which  the  commanded  attitude  error  may 
change  Vehicle  angular  rates  are  thereby  maintained  within  safe  limits.  The 
control  function  is  required  throughout  the  mission  although  the  frequency  of 
control  computations  is  higher  during  boost  than  during  orbit. 

During  the  boost  period,  when  control  is  provided  by  the  main  engine,  signifi- 
cant control  authority  with  relatively  fast  vehicle  response  is  available 
Therefore,  a high  iteration  rate  for  the  control  computations  is  required 
During  the  orbital  phase,  control  is  maintained  by  a reaction  jet  system  with 
limited  control  authority  Thus,  since  the  response  of  this  system  is  slow,  a 
relatively  slow  iteration  rate  for  control  computations  is  adequate 

Sequencing 

The  flight  program  functional  requirements  include  sequencing  of  the  discrete 
vehicle  events.  A limited  number  of  discrete  sequencing  requirements  are  sat- 
isfied by  use  of  the  discrete  outputs  of  the  central  computer  The  flight  pro- 
gram itself  must  sequence  into  the  different  phases  in  response  to  interrupts 
and  discrete  inputs  from  the  vehicle.  These  vehicle  interrupts  and  discrete 
inputs  signal  the  occurrence  of  specific  mission  events. 

The  vehicle  sequencing  requirements  are  based  on  the  occurrence  of  specific 
mission  events  Therefore,  the  vehicle  sequencing  requirements  are  divided  in- 
to several  distinct  series  of  commands.  Each  series  is  referenced  to  a speci- 
fied event  In  this  manner,  vehicle  sequencing  is  correct  in  spite  of  pertur- 
bations during  previous  mission  phases 

Telemetry 

Data  are  required  from  the  flight  program  during  its  operation  for  real  time 
monitoring  of  guidance  system  performance  and  for  detailed  post  flight  evalu- 
ation Real  time  data  generally  consists  of  the  state  vector,  error  or  backup 
indications,  vehicle  attitude,  and  program/vehicle  status,  mode,  sequencing, 
and  timing  information  Detailed  data  generally  consist  of  intermediate  guid- 
ance calculations  and  hardware  information.  These  data  are  transmitted  to  the 
ground  stations  through  the  Tug  telemetry  system 

Command  Processing 

The  Digital  Command  System  (DCS)  provides  the  capability  to  alter  certain  speci- 
fied flight  program  functions  and  data  upon  receipt  by  the  flight  program  of  the 
proper  commands  and  data  from  the  ground.  Soma  commands  will  require  only  a 
valid  mode  command  for  execution  while  others,  such  as  Navigation  Update,  re- 
quire a valid  mode  command  and  appropriate  data  for  execution  Through  use  of 
the  command  capability,  several  preplanned  alternate  modes  can  be  entered  or 
corrections  can  be  made  for  certain  predefined  off -nominal  performance  situa- 
tions or  vehicle  failures  through  the  update  and  generalized  sequencing  commands 
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The  flight  program  first  validates  the  mode  and  data  sequence  upon  receipt  of 
the  command  Appropriate  data  are  telemetered  to  the  ground  to  indicate  accept- 
ance and  validation  of  the  command  If  any  of  several  non-allowable  conditions 
exist  upon  receipt  of  a command,  such  as  invalid  command,  out  of  sequence  mode 
or  data,  or  valid  command  at  a wrong  time,  the  flight  program  transmits  the 
proper  error  message  to  the  ground  to  inform  flight  controllers  of  the  conditions 
so  that  appropriate  action  may  be  taken 

With  the  exception  of  the  Targeting  Load  command  and  the  other  commands  required 
to  support  it,  the  command  capability  is  only  required  during  the  coast  phase 
of  the  mission 

Table  9 5 4-1  presents  the  Tug  Flight  Software  sue  and  complexity  summary 


Table  9 5 4-1  Space  Tug  (Level  11)  Flight  Software  Sizing  Summary 


FUNCTION 

INSTRUCTIONS 

(WORDS) 

DATA 

(WORDS) 

COMPLEXITY 

EXECUTIVE 

• 

TASK  MANAGEMENT 

225 

345 

1 

• 

INTERRUPT  PROCESSING 

120 

50 

1 

• 

DISCRETE  PROCESSING 

45 

26 

3 

• 

TIMEKEEPING 

94 

45 

3 

• 

I/O  CONTROL 

100 

650 

3 

• 

INITIALIZATION/TERMINATION 

900 

83 

2 

• 

MATH  UTILITIES 

864 

— 

.3 

• COMMAND  DATA  POOL 

NAVIGATION 

1500 

• 

NAVIGATION  EXECUTIVE 

155 

51 

8 

• 

BOOST  NAVIGATION 

178 

69 

8 

• 

COAST  NAVIGATION 

1238 

192 

5 

• 

NAVIGATION  UPDATE 

591 

282 

.4 

t 

RENDEZVOUS  NAVIGATION 

2450 

406 

2 

• 

DOCKING  NAVIGATION 

1131 

317 

.2 

• 

IMU  ALIGNMENT 

2452 

822 

4 

• 

NAVIGATION  UTILITIES 

578 

125 

3 

GUIDANCE 

• 

GUIDANCE  EXECUTIVE 

83 

38 

.8 

• 

DOCKING  GUIDANCE 

1103 

279 

1 

• 

BURN  TERMINAL  GUIDANCE 

105 

37 

5 

e 

COAST  GUIDANCE 

254 

53 

.75 

• 

BURN  GUIDANCE  (IGM) 

1645 

280 

.25 

• 

TARGET  OPTIMIZATION 

3000 

160 

5 

• 

GUIDANCE  PRESETTINGS  COMP 

200 

— 

25 

• 

TARGET  UPDATE 

100 

— 

.5 
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Table  9.5.4-1.  Space  Tug  (Lave!  II)  Flight  Software  Sizing  Summary  (Continued) 


INSTRUCTIONS  DATA 

FUNCTION  (WORDS)  (WORDS)  COMPLEXITY 

TELEMETRY 


ATTITUDE  CONTROL 


• 

INITIALIZATION 

64 

30 

.75 

• 

UPDATE  ATTITUDE 

15 

3 

9 

• 

COMPUTE,  TRANSFORM  ERRORS 

43 

11 

.9 

• 

BURN  CONTROL  LAW 

233 

32 

.5 

• 

COAST  CONTROL  LAW 

64 

23 

6 

e 

CONTROL  OUTPUTS 

106 

23 

1.0 

SEQUENCING 

• 

NORMAL  COMMAND  ISSUANCE 

224 

21 

6 

• 

ERROR  PROCESSING 

195 

28 

.4 

• 

NOMINAL  PROCESSING  TABLE 

51 

9 

4 

• 

ALTERNATE  TABLE  PROCESSING 

47 

11 

.4 

• 

DATA  TABLES 



1700 

___ 

i 

BLOCK  MAINTENANCE 

169 

30 

5 

• 

RECORDER  CONTROL 

161 

34 

75 

• 

STATION  VECTORS  [10) 

— 

30 



UPLINK 

PROCESSING 

• 

READ  INPUT 

211 

34 

,4 

• 

MESSAGE  PROCESSING 

154 

35 

6 

• 

MESSAGE  ACKNOWLEDGEMENT 

53 

6 

9 

• 

ERROR  PROCESSOR 

66 

10 

75 

t 

DATA  OUTPUT 

38 

6 

1 0 

• 

DATA  BUFFER 

— 

100 

— 

t 

FUNCTION  PROCESSING 

1300 

100 

.25 

IMU  PROCESSING 

t 

READ  INPUT  DATA 

50 

12 

1.0 

• 

FILTER  AND  CONVERT  DATA 

100 

108 

5 

• 

BODY-TO- INERTIAL  TRANSFORMATION 

50 

9 

4 

• 

IMU  REDUNDANCY  MGT 

800 

60 

2 
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9 5 5 GROUND  DATA  SYSTEM 


The  central  computer  within  the  Tug  control  center,  through  its  software,  is 
the  focal  point  for  the  entire  mission  support  operation  The  computer  must 

support  a myriad  of  capabilities  - examples  of  which  are  listed  below 

• Mission  Program  Development  and  Test 

• System  Simulation 

» Scientific  Computation 

• Training  of  Flight  Controllers 

• Real-Time  Support  of  Tug  Mission 

• Schedule  and  Control  Jobshop  Work 

Because  of  the  criticality  of  the  Central  Computer  to  the  overall  operation, 
it  is  essential  that  the  computer  selected  be  capable  of  handling  all  planned 
functions  in  an  orderly  fashion  and  also  provide  sufficient  growth  capability 
to  support  changing  requirements  as  the  Tug  program  matures  The  growth  fac- 
tor is  particularly  significant  in  view  of  the  fact  that  the  RTCC  software 
required  for  support  of  the  Apollo  Program  expanded  by  approximately  50  per- 
cent during  that  program  As  a result,  the  central  computer  became  marginal, 
in  some  instances,  m its  ability  to  perform  the  burden  of  work  placed  on  it 

9551  Computer  Selection  Considerations 

The  principal  driving  factors  in  the  selection  of  a computer  system  are  the 
memory  capacity  of  the  computer  and  its  Central  Processing  Unit  (CPU)  capabil- 
ities. Additional  factors  to  be  considered  are  peripheral  device  capabilities 

and  the  ability  to  interface  with  special  devices  required  in  the  Tug  control 
center  The  following  paragraphs  discuss  the  primary  factors  of  memory  capacity 
and  CPU  capabilities  as  they  relate  to  the  Tuq  control  center  central  computer 

95511  Memory  Capacity 

The  total  size  of  the  system  software  required  to  support  the  Tug  mission  is 
728,114  words  However,  it  is  not  necessary  for  the  entire  program  to 
continuously  reside  in  main  memory  Through  a proper  structuring  of  the 
software  system,  a significant  amount  of  the  program  can  be  placed  on 
auxiliary  storage  devices  to  be  read  into  main  memory  when  required  This 
technique  will  reduce  the  demand  for  core-resident  programs  and,  therefore, 
reduce  the  main  memory  capacity  requirements,  however,  the  use  of  auxiliary 
storage  will  require  significant  input/output  operations  which  may  affect  the 
ability  of  the  system  to  satisfy  response  time  requirements 

In  selection  of  the  computer,  a maximum  case  mam  memory  requirement  must  be 
established  Through  analysis  of  the  software  functional  requirements,  it 
was  determined  that  the  maximum  memory  utilization  case  for  the  Tug  control 
center  would  occur  when  the  executive,  vehicle  system,  and  mission  profile 
modules  of  the  mission  program  software  were  required  simultaneously 

As  shown  in  Table  9 5.5-1,  such  a combination  of  software  would  require 
approximately  348,450  words  of  mam  memory  Vehicle  system  software  consists 
of  the  downlink  processing  module  and  the  uplink  processing  module,  which 
collectively  require  128,350  words  of  storage,  if  all  vehicle  system  soft- 
ware were  simultaneously  m mam  memory  Worst  case  analysis  has  shown 


9-62 


that  the  maximum  simultaneous  requirement,  however,  is  only  65  percent  of 
the  total  vehicle  software  This  reduces  the  actual  storage  load  to  83,427 
words 

The  mission  profile  module  total  word  requirement  is  159,790  words,  as  shown 
on  Table  9 5.3-8,  of  which  34.8  percent  is  the  maximum  simultaneous  require- 
ment This  adds  55,607  words  to  the  total  simultaneous  memory  requirement. 

The  control  software  cosists  of  the  executive  system  module  and  the  control 
center  support  module,  which  collectively  require  256,134  words  of  storage 
The  maximum  simultaneous  requirement  rs  81  76  percent  of  the  total  control 
software  This  adds  209,415  words  to  the  total  simultaneous  memory  require- 
ments . 


Table  9.S.S-1  Co-Resident  Summary  Requirements 


FUNCTION 

WORDS 

CONTROL 

209,  415 

VEHICLE  SYSTEM 

83,427 

MISSION  PROFILE 

55,607 

TOTAL 

348,449 

TOTAL  + GROWTH  FACTOR 

696,898 

9.5.5  1 2 CPU  Utilization 

CPU  capability  is  defined  to  be  the  number  of  operations  a computer  can  per- 
form within  a one  second  interval  In  selection  of  the  central  computer,  it 
is  required  that  the  computer  have  sufficient  computational  capability  to 
perform  all  defined  functions  within  the  specified  time  constraints  As  in 
the  case  of  memory  capacity,  CPU  growth  capability  must  also  exist  for 
additional  computational  requirements  as  the  Tug  Program  matures 

Within  the  Tug  control  center,  the  principal  factors  which  directly  affect 
the  CPU  requirements  are 

• Software  execution  rates 

• Input/output  requirements 

o Response  times  to  user  requests 

The  determination  of  CPU  execution  rates  for  a proposed  computer  system  is 
a detailed  effort  requiring  the  use  of  extensive  modeling  techniques  These 
modeling  techniques  require  a detailed  knowledge  of  software  module  content 
and  frequency  of  operation  The  preliminary  nature  of  software  module 
definition  contained  in  this  study  precludes  the  use  of  such  techniques  and, 
therefore,  an  alternate  approach  was  taken. 

The  functional  similarities  between  the  RTCC,  JPL,  and  TOC  requirements 
provide  a means  whereby  an  analysis  of  extending  system  CPU  utilization  can 
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establish  a baseline  for  CPU  requirements  Because  the  RTCC  is  a "man  rated", 
real-time  system,  its  CPU  utilization  was  selected  as  an  upper  bound  A 
minimum  bound  was  established  from  the  JPL  operation,  which  is  a non-man 
rated,  non-real -time  system 

Control  Center  Computer  execution  rates  were  then  assumed  to  be  greater  than 
the  JPL  operation  and  less  than  the  RTCC  Through  comparative  statistics, 
it  was  established  that  the  maximum  case  CPU  utilization  would  require  20 
percent  less  than  the  RTCC  maximum  Table  9 5 5-2  documents  the  statistics 
for  the  subject  control  centers 

The  75  percent  maximum  utilization  for  the  TOC  when  applied  to  the  360/75 
Model  J,  results  m a maximum  CPU  utilization  of  3 85  x 106  operations/second 
required  of  the  Control  Center  central  computer 

Table  9 5.5-2.  Control  Center  CPU  Utilization 


CONTROL  CENTER* 

% CPU  UTILIZATION 

MIN 

MAX 

AVG 

RTCC  (APOLLO) 

40 

95 

50 

JPL 

10 

60 

12-15 

TOC  (PROJECTED) 

30 

75 

40 

* Computer  System  IBM  360/75,  Model  J g 
Cycle  Time  - 195  Nanoseconds,  5 128  x 10°  Operations/Second 


95513  Growth  Considerations 

As  has  been  stated  previously,  growth  capability  in  both  memory  capacity 
and  CPU  capability  must  be  considered  in  computer  selection  IBM's  previous 
experience  on  similar  ground  control  centers  (RTCC  and  JPL)  indicate  that 
growth  potential  in  both  areas  should  be  approximately  50  percent  to  satisfy 
requirements  Failure  to  provide  for  this  growth  can  severely  restrict  the 
ability  of  the  IUS  control  center  to  expand  with  the  increasing  requirements 
placed  upon  it  A major  objective  in  selecting  the  central  computer  should 
be  to  provide  for  orderly  growth  in  capability  throughout  the  lifetime  of  the 
center 

9552  Candidate  Computers  and  Selection 

As  was  developed  previously,  the  mam  memory  capacity  must  be  a minimum  of 
348,449  words  to  handle  maximum  case  memory  requirements,  and  the  CPU 
capability  must  provide  3 85  x 106  operations/second  An  additional  100 
percent  increase  in  these  capabilities  to  provide  the  desired  growth  capacity 
yields  the  following  characteristics  the  candidate  computers  must  satisfy 

• Memory  capacity  - 696,898 

• CPU  capability  - 7 7 million  operations/second 
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The  candidate  computers,  within  the  IBM/370  line,  which  should  be  considered 
for  the  ground  control  center  application  with  the  growth  capability  provided, 
are  shown  in  Table  9 5 5-3 


Table  9 5 5-3  Candidate  Computers 


THE  LIST  OF  CANDIDATE  COMPUTER  SYSTEMS  (IN  ASCENDING  ORDER  OF  INSTALLED  COST) 

MEETING  OR  EXCEEDING  THE  MAIN  MEMORY  AND 

CPU  CRITERIA  IS 

INSTALLED 

YEARLY 

REQ'D 

MEMORY 

CPU  SPEED 

SYSTEM 

MODEL 

COST 

MAINTENANCE 

AREA 

(MEGA  WORDS) 

(MEGA  OPS/SEC) 

1 

3158 

MP5 

6205376 

134458 

3024 

79 

8 70 

2 

3158 

MP6 

6711376 

138795 

3024 

1 05 

8.70 

3 

3168 

MP3 

9811661 

276393 

3024 

79 

12  50 

4 

3168 

MP4 

10317601 

281730 

3024 

1 05 

12  50 

5 

3168 

MP5 

10931201 

291071 

3024 

1 31 

12  50 

6 

3168 

MP6 

11437201 

295408 

3024 

1 57 

12  50 

7 

3168 

MP7 

11943201 

299745 

3024 

1 84 

12  50 

8 

3168 

MP8 

12449201 

304081 

3024 

2 10 

12  50 

From  the  preliminary  analysis  conducted  in  this  study,  the  370/158-MP6  appears 
to  be  the  minimum  cost  computer  which  provides  the  desired  growth  potential 

Prior  to  actual  selection  of  a computer  for  the  ground  control  center  for  the 
Tug  missions,  an  extensive  modeling  study  should  be  conducted  This  study 
should  utilize  the  system  requirements  and  software  definition  and  develop  a 
detailed  model  of  the  control  center  computer  system  From  this  model, 
detailed  statistics  can  be  gathered  regarding  such  items  as  main  memory 
requirements,  CPU  utilization,  auxiliary  storage  utilization,  and  system 
response  times  All  of  these  data  can  then  be  utilized  to  determine  the 
most  cost-effective  computer  system  for  the  control  center 


9 6 PHYSICAL  PLANT 

It  has  been  assumed  for  the  purposes  of  this  study  that  no  existing  facilities 
will  be  utilized  This  requires  that  a separate  physical  plant  be  designed 
to  house  the  flight  control,  flight  support,  data  system,  and  staff  equip- 
ment areas  required  to  support  the  operation  functions 

The  only  variable  which  controls  a portion  of  the  physical  plant  design  is 
the  number  of  consoles  required  by  the  flight  control  personnel  and  the 
flight  support  personnel  This  parameter  varies  as  a function  of  the  opera- 
tional philosophy  and  data  display  requirements 

Figure  9.6  0-1  presents  a representative  floor  plan  for  a typical  concrete 
block,  slab  foundation  structure,  114  feet  by  90  feet,  to  house  the  flight 
control  functions  It  is  assumed  that  the  government  will  contract  the 
construction  of  the  physical  plant  and  therefore,  cost  to  the  government  will 
be  in  two  phases  (1)  those  costs  involved  in  administering  and  overseeing 
the  contract  during  the  period  of  its  execution  and  (2)  the  procurement  cost 
of  the  completed  building 
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Figure  9 6.0-1  Representative  Floor  Plan  and  Staff  Stations 


Procurement  costs  are  estimated  on  the  following  basis 

Raised  floor  construction  - areas  requiring  subfloor  cabling,  air 
conditioning,  etc  , will  cost  $50.00  per  square  foot  to  construct 

Ordinary  floor  construction  cost  $35.00  per  square  foot  to  construct 

Figure  9.6  0-1  depicts  a representative  floor  plan  with  sufficient  capacity 
for  the  personnel  and  equipment  specified  m this  study.  Total  area  for  this 
particular  TOC  layout  is  9,836  square  feet  of  which  the  following  alloca- 
tion of  space  is  tabularized  in  Table  9.6  0-1. 

Table  9 6.0-1.  TOC  Area  Space  Allocation 


TOC  AREA 

SQUARE  FEET 

Flight  Control  Room 

1100 

Viewing  Room 

243 

Flight  Support  Room 

500 

Computer  Support  Area 

594 

Tape  Storage 

255 

Office,  Restrooms,  Canteen 

1080 

Technical  Support  Area 

1296 

Mechanical  Support  Area 

612 

Data  System  Area 

3024 

Hall /Lobby 

1132 

TOTAL 

9836 

The  prime  considerations  in  developing  this  configuration  were  separation  of 
functions,  equipment  space  requirements,  and  operations  staff  positions 
locations. 

Space  allocation  for  display  consoles  in  the  Flight  Control  Room  and  Flight 
Support  Room  are  based  on  a standard  6x4  foot  console  with  a six  foot 
separation  between  console  rows  for  chair,  bookcase  and  passage  Console 
arrangement  is  based  on  operational  function  and  console  operator  duty  This 
orderly  arrangement  of  consoles  groups  teams  with  similar  responsibilities  and 
consoles  with  supervisory  and  summary  displays.  This  provides  efficient 
mission  support  during  high  and  low  mission  phase  activity.  It  is  of  partic- 
ular significance  during  low  activity  phases  where  manning  is  minimal 
Operational  positions  that  are  manned  are  adjacent  permitting  efficient 
monitoring  all  of  active  Tug  vehicle  systems  during  this  period.  Consoles 
in  the  Flight  Control  and  Support  Rooms  face  the  Technical  Support  Area. 

This  arrangement  accommodates  the  utilization  of  special  large  screen  displays 
should  this  be  desired.  The  space  allocated  in  the  Data  Systems  Area  is 
comparable  to  current  space  requirements  for  all  equipment  associated  with 
a dual  IBM  System  370/158. 
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9 7 COST  ESTIMATES 


The  two  key  elements  to  the  cost  estimate  methodology  are  the  involvement 
matrix  and  the  cost  analysis  programs  The  involvement  matrix  is  constructed 
by  analyzing  the  mission  timeline  modules  and  placing  each  subfunction  within 
each  timeline  module  on  the  vertical  axis  of  the  involvement  matrix,  and  by 
analyzing  the  support  characteristics  of  the  operational  elements  on  the 
horizontal  axis  of  the  matrix  The  operational  autonomy  was  then  used  as  a 
guide  for  establishing  the  involvement  of  a mission  timeline  subfunction  with 
a support  element  The  involvement  matrix  thus  establishes  a relationship 
between  Space  Tug  missions  and  the  support  requirements  of  the  Space  Tug  missions, 
which  is  then  used  as  a data  base  for  analyzing  these  relationships 

The  major  output  from  the  involvement  matrices  are  support  requirements  This 
is  a summary  of  the  impact  the  mission  structure  has  upon  the  ground  support 
structure 

In  parallel  with  the  manipulation  of  the  involvement  matrices,  reference 
missions  were  constructed  by  sequencing  mission  modules  into  modular  time- 
lines These  modular  timelines  are  utilized  in  the  cost  analysis  programs 
to  establish  shift  density,  overlap  of  modules  and  overlap  of  missions  when 
compared  to  the  associated  traffic  model  in  the  cost  analysis  programs  The 
cost  analysis  programs  accept  inputs  from  the  traffic  model,  support 
requirements,  and  the  modular  timelines,  then  produce  a detail  printout  of 
DDT&E  expenses  and  recurring  cost  expenses  Figure  9 7 0-1  illustrates 
the  Tug  methodology. 

971  Involvement  Matrix 

The  involvement  matrix  is  a 277  row  by  137  column  matrix  which  defines  the 
involvement  of  the  operational  elements  with  the  operational  functions  in  the 
covering  set  of  mission  operations  requirements  The  involvement  matrix 
provides  a method  of  quantifying  the  effects  of  variations  in  support 
technique  and  variations  in  mission  operations  functions.  The  difference 
between  the  number  of  relations  involved  in  Level  II  autonomy  support  and  in 
Level  III  autonomy  support  provides  a direct  process  of  quantifying  the  support 
element  requirements  During  the  study  progress,  it  has  been  demonstrated  that 
the  involvement  matrix  is  a valuable  tool  for  the  quantification  of  support 
elements  and,  therefore,  can  be  utilized  to  establish  a comparative  relationship 
between  cost  and  autonomy  level  Figure  9 7 1-1  presents  the  involvement 
matrix.  The  137  operational  elements  are  listed  across  the  top  of  the 
matrix  The  277  mission  operational  functions  and  subfunctions  are  listed 
vertically. 

9711  Autonomy  Level  Differential 

Figure  9 7 1-2  shows  a typical  set  of  Involvement  Matrices,  one  for  Level  III 
autonomy,  one  for  Level  II  autonomy,  with  the  involvements  indicated  by  a "1" 
entry  in  the  matrix  cells  and  no  involvement  by  a "0"  in  the  matrix  cells 
By  analysis  of  the  differences  in  involvement,  the  support  requirements  may 
be  ascertained  It  will  be  noted  that  the  involvement  matrix  is  merely  a 
convenient  organization  tool  for  the  exploration  of  inter- related  factors 
The  validity  of  the  matrix  lies  in  the  effort  expended  by  knowledgeable 
flight  control  systems  engineers  in  analyzing  the  operations 
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Figure  97  7-1.  Involvement  Matrix 
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9712  Autonomy  Level  Differentiation  Example 

Figure  9 7 1-3  highlights  one  line  of  entries  for  control  center  involvement 
That  line  is  relative  to  the  initialization  of  guidance,  navigation  and  con- 
trol systems  and  the  alignment  of  the  inertial  measuring  unit  prior  to  a 
mam  stage  burn  It  will  be  noted  that  there  are  four  differences  (additions) 
between  Level  II  and  Level  III  implementations  Those  four  differences  are 
in  the  requirement  for  1)  command  process,  2)  command  generation,  3)  command 
validation,  and  4)  data  transfer  outside  the  Tug  operations  center  All  of 
the  foregoing  are  required  to  provide  a ground  command  interface  with  the  Tug 
vehicle  The  significance  in  that  partial  row  (Level  II)  is  that  the  onboard 
system  is  not  entirely  responsible  for  functions  required  to  initialize  the 
guidance,  navigation  and  control  system  and  can  thus  rely  upon  the  ground 
for  some  level  of  assistance  in  accomplishing  those  funcions  In  turn,  flight 
software  may  be  reduced,  at  the  expense  of  increasing  ground  software  and 
ground  manning  requirements  Costs  can  then  be  associated  with  each  of  the 
two  related  functions  and  the  cost  optimal  implementation  selected. 

9713  Cost  Analysis  Programs 

Fifteen  cost  analysis  programs  have  been  used  to  investigate  various  aspects 
of  the  support  element  cost  Figure  9 7 1-4  presents  the  flow  of  logic  as 
implemented  in  the  analytical  software  which  creates  the  total  development 
costs  and  total  recurring  costs  for  an  operational  concept  The  inputs  to 
and  the  outputs  from  the  operations  are  illustrated  The  software  active 
during  the  various  processes  are  displayed  by  their  mnemonic  designators 
placed  in  the  elliptical  bubbles  near  the  operations  Cost  output  information, 
that  is,  printouts  available  of  the  programs,  are  enclosed  in  rectangular 
boxes  with  either  the  letter  D or  the  letter  R entered  in  the  box,  indicating 
the  final  utilization  of  the  derived  cost  in  either  the  DDT&E  summation  or 
the  recurring  cost  summation,  or  both  A sixteenth  program,  which  analyzes 
the  alternate  concepts  of  mission  operations,  was  utilized  in  the  generation 
of  prior  study  results 

97.2  DDT&E  Costs  - Level  II  Space  Tug 

First  estimates  of  DDT&E  costs  have  been  derived  for  the  Level  II  Tug,  by 
using  the  cost  analysis  programs  presented  in  a previous  section  These 
estimates  encompass  all  "deliverable"  end  items  in  the  Tug  program,  but  do 
not  contain  cost  elements  which  have  intermediate,  or  planning  type  outputs 
The  cost  analysis  programs  account  for  90%  of  the  DDT&E  expenses  A detailed 
examination  of  the  Work  Breakdown  Structure  (WBS)  presented  in  Volume  V will 
identify  the  elements  not  priced  by  the  cost  analysis  programs 

Figure  9 7.2-1  presents  the  Ground  Software  DDT&E  cost  estimate 

Figure  9 7 2-2  presents  the  Flight  Software  DDT&E  cost  estimate 

for  the  flight  software 

Figure  9 7 2-3  presents  the  Data  System  DDT&E  costs. 

The  operational  console  hardware  is  tabulated  in  Table  9 7.2-1 

Figure  9 7 2-4  represents  the  physical  plant  DDT&E  costs. 
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STANDARD  MAINSTAGE  MODULE 
IMPLEMENTATION  REQUIREMENTS 

Entry  On-orbit  navigation  and  targeting  has  computed 
requirement  necessitating  full  thrust  (15,000  1, 
of  the  Space  Tug  Main  Engine 

Exit  The  Space  Tug  has  entered  the  desired  trajectory 
on-board  guidance,  and  has  been  configured  for  c< 
Navigation  errors  are  converging 
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Figure  9 7.1-3  Autonomy  Level  Differentiation 
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Figure  9 71-4  Cost  Analysis  Programs 
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THE  CONSTANTS  USED  IN  COMPUTING  GND  SFTWR  COSTS  BY  THIS  FUNCTION  ARE 

1)  WORKING  BAYS /MONTHS  = 21 

2)  COMPUTER  WORDS /INSTRUCTION  = 1 

3)  PROGRAMMER  PRODUCTIVITY  { INST  LINES /DAY)  = 14 

4)  COMPUTER  WORDS /DATA  = 4 

5)  PROGRAMMER  PRODUCTIVITY  { DATA  LINES /DAY)  =30 


INSTRUCTION 

INSTRUCTION 

DATA 

DATA 

SIZE 

COST 

SIZE 

COST 

COMPLEXITY 

TOTAL 

PROGRAM 

{WORDS) 

\ 

{ DOLLARS ) 

{WORDS) 

CD) 

FACTOP 

CD) 

DOWNLINK  PROCESSING 

68190 

927755 

12540 

19905 

1 00 

947660 

UPLINK  PROCESSING 

32980 

448707 

14640 

23238 

1 00 

471946 

MISSION  PROFILE 

109760 

1991111 

50030 

79413 

.75 

2070524 

EXECUTIVE 

2109001 

5738776 

29304 

46514 

.50 

5785290 

CONTROL  CENTER  SUPPORT 

12690 

345306 

3240 

5143 

50 

350449 

DATA  COMMUNICATIONS 

0 

0 

0 

0 

.50 

0 

SIMULATION  SYSTEM 
TOTALS 

136800 

2481633 

11933288 

47040 

74667 

248879 

75 

2556299 

12182167 

Figure  9 7 2-1  Ground  Software  DDT&E  Costs 


THE  CONSTANTS  USED  IN  COMPUTING  FIT  SFTWR  COSTS  BY 
THIS  FUNCTION  ARE 

1)  WORKING  DAYS /MONTH  = 21 

2)  COMPUTER  WORDS /INSTRUCTION  = 1 

3)  PROGRAMMER  PRODUCTTVITY  ( INST  LINES /DAY)  =69 

4)  COMPUTER  WORDS /DATA  = 4 

5)  PROGRAMMER  PRODUCTIVITY  ( DATA  LINES /DAY)  = 30 


INSTRUCTION 

INSTRUCTION 

DATA 

DATA 

SIZE 

COST 

SIZE 

COST 

TOTAL 

PROGRAM 

(WORDS) 

(DOLLARS') 

(WORDS) 

(D) 

( D ) 

DOWNLINK  PROCESSING 

330 

34632 

94 

339 

34971 

UPLINK  PROCESSING 

1822 

386577 

291 

1049 

387626 

EXECUTIVE 

2348 

728572 

2699 

9725 

738297 

SEQUENCING 

517 

69296 

1769 

6374 

75670 

GUID  ,NAV  AND  CNTL 

16788 

3809795 

3422 

12330 

3822125 

TOTALS 

5028872 

29816 

5058689 

Figure  9 7 2-2  Flight  Software  DDT&E  Costs 
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COMMUNICATION 
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_ STATIONS  ON  EACH 
CONSOLE 


DATASYS  COST 

ENTER  THE  UNIT  COST  (IN  DOLLARS ) FOR  EACH 
OF  THE  FOLLOWING  ELEMENTS 
MASTER  CLOCK 
0 

1(4560 

NTWK  TERMINAL  EQUIP. 

0 

20900 

TTY  PRINTER  KEYBOARD 

□ 

3172 

INTERCOM  EQUIP. 

□ 

230000 

VIDEO  SWITCH 

0 

5610 

DATA  SYSTEM  COST 


ITEM  COST 


3158  MP 5 

6205376 

MASTER  CLOCK 

44560 

NTWK.  TERMINAL  EQUIP. 

20900 

TTY  PRINTER  KEYBOARD 

3172 

INTERCOM  EQUIP. 

230000 

VIDEO  SWITCH 

5610 

TOTAL 

6509618 

Figure  3 72-3  TOC  Support  Hardware  DDT&E  Costs 
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SO 

P/SQ 

COST 

TOC  AREA 

FT 

FT 

uu 

&IGINAL  PAGjS  IS 

FLIGHT  CONTROL  ROOM 

1100 

50 

55000 

FLIGHT  SUPPORT  ROOM 

500 

50 

30000 

>F  POOR  QUALITY 

DATA  SYSTEM  AREA 

3024 

SO 

151200 

VIEWING  ROOM 

243 

35 

8505 

COMPUTER  SUPPORT  AREA 

594 

35 

20790 

- 

TAPE  STORAGE 

255 

35 

8925 

OFFICES , RESTROOMS , CANTEEN 

1080 

35 

37800 

TECHNICAL  SUPPORT  AREA 

1296 

35 

45360 

MECHANICAL  SUPPORT  AREA 

612 

35 

21420 

HALL /LOBBY 

1132 

35 

39620 

TOTAL 

9836 

413620 

ENTER  THE  AREAS  ( IN  SQ  FT  TAPE  STORAGE 

MECH  SUPPORT  AREA 

VIEWING  ROOM 

□ 

[J 

□ 

255 

612 

243 

OFFICES , RESTROOMS, 

CANTEEN 

llALL/LOBBY 

COMPUTER  SUPPORT  AREA  □ 

□ 

□ 

1080 

1132 

594  TECH  SUPPOET  AREA 


□ 

1296 

Figure  9 72-4  Physical  Plant  DDT&E  Costs 
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Table  9.72-1  Consoles  and  Hardware  Costs 


Equipment  Item  Quantity 

Unit  Cost 

Total  Cost 

Console 

16 

4,800 

76,800 

Communication  Panel 

27 

6,000 

162,000 

TV  Monitor 

32 

2,000 

64,000 

Event  Monitor 

62 

8,000 

496,000 

MED 

17 

6,400 

108,800 

Command  Panel 

9 

7,200 

64,800 

Display  Control  Panel 

16 

2,000 

32,000 

TOTAL 

1,004,400 

Table  9. 7. 2-2  summarizes  the  total 

DDT&E 

costs  output  by  the  cost  analysis 

programs 

Table  9. 7. 2-2  Total  Tug  DDT&B  Cost  Summary 

El ement 

Dollars 

Physical  Plant 

413,620 

TOC  Software  Development 

12,182,167 

Data  System 

6,509,618 

Operations  Staff  Equipment 

1,004,400 

Tug  Software  Development 

5,058,689 

TOTAL 

25,168,494 

9 7 3 Recurring  Costs  - Level  II  Space  Tug 

The  recurring  costs  incurred  in  orbital  operations  and  mission  support  are  in 
the  main  service  type  costs,  since  there  are  no  major  hardware  refurbishments 
involved.  The  types  of  costs  included  are  facility  maintenance,  ground 
software  update  and  maintenance,  data  system  maintenance,  flight  software 
maintenance,  sustaining  facilities  engineering,  sustaining  flight  control 
engineering  and  network  rental  expenses.  Of  these  tasks,  facility  maintenance 
and  data  system  maintenance  will  be  contracted  to  outside  agencies  Ground 
software  update  and  maintenance  will  be  accomplished  by  the  permanently  assigned 
software  support  team.  The  sustaining  facilities  engineering  and  sustaining 
flight  control  engineering  personnel  will  perform  all  pre-mission  preparations, 
training  and  conduct  of  mission  operations.  Network  rental  will  be  charged 
to  the  Operations  organization  on  the  basis  of  the  number  of  hours  utilized 
and  the  type  of  service  rendered.  The  flight  software  maintenance  tasks 
are  those  tasks  involved  in  defining,  programming  and  verifying  mission 
specific  deviations  from  the  basic  four  flight  programs.  This  is  largely  a 
manpower  expense.  Computer  time  will  be  provided  by  the  control  center  computer 
at  no  cost. 

9 7.3.1  Facility  Maintenance 

Facility  maintenance 'includes  refuse  disposal,  janitorial  services,  internal 
electrical  maintenance,  internal  power  and  heating  maintenance,  internal 
painting,  air-conditioning  costs,  exterior  painting,  roofing,  and  parking 
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lot  maintenance  Facility  maintenance  costs  commonly  are  based  upon  a constant 
of  approximately  $1  32  for  government  installations  and  $2  00  for  industrial 
installations  The  cost  of  facility  maintenance  is  computed  from  the  estimated 
number  of  square  feet  required  by  the  operations  and  support  areas  multiplied 
by  $2  00  per  square  foot  This  expense  is  approximately  $20,000  per  year 

9732  Ground  Software  Update  and  Maintenance 

The  approach  chosen  to  develop  this  algorithm  divides  the  software  maintenance 
task  into  two  subtasks  The  first  subtask  consists  of  finding  and  fixing 
software  problems,  supporting  system  operation,  and  installing  nominal  mission- 
to-mission  program  enhancements  The  second  subtask  consists  of  adding  new 
functions  and  performing  major  modifications  to  the  existing  software  system 

The  cost  of  the  former  can  best  be  sized  as  a "level  of  effort"  task  Since 
software  problems  will  probably  be  discovered  throughout  the  software  system, 
a level  of  expertise  must  be  maintained  through  the  availability  of  personnel 
familiar  with  every  software  area  The  number  of  personnel  required  for  each 
area  is  dependent  on  the  size,  complexity,  criticality,  and  level  of  mission- 
to-mission  changes  for  the  programs  therein 

The  level  of  effort  will  decrease  as  a function  of  time  Saturn  Launch 
Computer  Complex  data  indicates  that  the  number  of  software  problems  decreased 
by  more  then  50%  during  the  first  year  of  system  operation  After  the  first 
year,  the  number  of  problems  should  continue  to  decrease  but  at  a much  slower 
rate 

The  cost  of  the  second  subtask  is  similar  to  that  of  new  software  development 
Two  offsetting  attributes  of  modification/extension  work  affect  this  cost 
The  first  is  that  adding  new  functions  to  an  existing  working  system  is  easier 
than  new  work  due  to  the  existence  of  well  defined,  operational  interfaces  and 
system  services  The  second  attribute  applies  to  modifications 

Modifications  usually  require  a significantly  greater  degree  of  design  and 
system  testing  than  the  number  of  instructions  involved  would  indicate 
Modifications  in  inter-program  interfaces  can  spread  through  larger  parts  of 
the  system  causing  subtle  problems  which  require  extensive  system  testing 
Given  these  offsetting  factors  and  assuming  a reasonable  mixture  of  the  two, 
we  can  approximate  these  costs  by  using  the  same  cost  algorithm  as  used  for 
new  development  work 

9733  Data  System  Maintenance 

Standard  rate  schedules  exist  for  the  maintenance  of  large-scale  computer 
systems  and  the  associated  peripheral  gear.  For  the  data  systems  chosen, 
the  data  system  maintenance  costs  are  approximately  $135,000  per  year  for  the 
Tug  program  Maintenance  of  all  other  equipment  will  be  a responsibility  of 
the  sustaining  flight  support  engineering  organization 
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9 7 3.4  Sustaining  TOC  Engineering 

A certain  minimum  staff  is  required  to  control  and  support  the  control  of  a 
Tug  vehicle  That  staff  is  divided  into  two  major  groupings — the  flight  support 
group  (Sustaining  Engineering)  and  the  flight  control  group.  There  are  30 
personnel  required  to  staff  the  flight  support  organization  on  a continuing 
basis.  These  people  have  been  costed  at  $48,000  per  man  per  year 

The  size  of  the  staff  is  established  by  the  real-time  support  requirements 
However,  the  staff,  during  non-mission  and  non-training  periods,  is  to  be 
utilized  to  perform  mission  preparations  and  maintenance  jobs  This  multiplex- 
ing of  personnel  is  cost-effective  in  that  it  spreads  the  productive  work  load 
of  the  permanently  assigned  personnel  more  evenly  across  the  operational 
periods 

9 7 3.5  Sustaining  Flight  Control  Engineering 

There  is  a specific  minimum  staff  required  to  control  the  Tug  vehicle  during 
mission  operational  periods.  For  the  Tug  program,  that  staff  requirement  is 
30  flight  control  engineers  The  flight  control  organization  is  a required 
sustaining  engineering  staff  which  may  be  utilized  during  non-mission  periods 
in  performing  preparation  tasks,  such  as  training,  scheduling,  and  interface 
type  operations.  As  with  the  flight  support  staff,  the  spreading  of  effort 
across  the  period  of  operations  is  a cost-effective  utilization  of  the  flight 
control  staff 

9736  Network  Rental 

In  order  to  arrive  at  a minimum  network  rental  cost,  Philco-Ford  designed  a 
system  for  the  transmission  of  telemetry,  command,  tracking  and  television 
data  from  six  STDN  remote  sites  to  the  Tug  operations  control  center.  This 
network  utilized  commercial  carrier  satellite  transmission  directly  from  the 
ground  station  to  the  operations  control  center  Figure  9.7  3-1  presents 
the  network  and  terminal  cost  data  derived  by  Philco-Ford. 

To  implement  the  network,  each  of  the  remote  stations  requires  a line  terminal 
installation,  which  creates  a recurrnng  cost  of  $31,700  per  month.  The  line 
terminal  equipment  at  the  remote  stations  feed  commercially  available  common 
carrier  single-sideband  data  links  at  a composite  leased  cost  of  $284,830 
per  month  The  leased  lines  are  demultiplexed  at  the  operations  center  by 
three  line-terminal  stations. 

It  is  assumed  that  no  costs  will  be  incurred  to  rent  the  ground  station  equip- 
ment itself,  that  is,  the  data  being  fed  to  the  line  terminals  at  the  STDN 
sites  are  supplied  free  of  charge  to  the  Tug  program  by  GSFC  It  is  also 
assumed  that  the  terminal  stations  within  the  operations  center  are  costed 
as  a portion  of  the  network  terminal  fees  and  are  not  part  of  the  network 
rental  computation.  The  summation  of  the  recurring  costs  of  network  leasing 
per  month  and  the  STDN  site  stations  per  month  are  $475,030.  To  arrive  at 
a minimum  cost,  the  operation  of  the  TDRS  system  was  assumed  This  reduced 
the  monthly  cost  of  ground  station  terminal  equipment  from  $190,200  to  $31,700 
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STDN  SITE 
(6  STATIONS) 
$190,200 


COMMON  CARRIER 
60  108  KHzLSB 
(LEASED) 
$284,830/M0 


TOC  SITE 
(3  STATIONS) 
$234,000 


STATION  DESIGN  AND  DEVELOPMENT  COST  $215,000 


Figure  9 73-1  Network  and  Terminal  Cost  Data 


This  was  arrived  at  by  assuming  the  TDRS  ground  station  would  be  provided  with 
the  terminal  equipment  and  a fee  equivalent  to  the  leased  line  cost  from  the 
6 STDN  stations  would  be  imposed. 

The  summation  of  a single-station  line  terminal  installation  and  the  leased 
line  costs  is  $316,530.  Since  these  are  leased  costs,  it  is  assumed  that 
the  hourly  cost  would  be  equivalent  to  dividing  the  summation  of  leased  line 
cost  and  ground  station  recurring  cost  by  the  number  of  hours  of  operation  in 
a month  This  gives  an  hourly  rate  of  $430.  Now,  the  network  rental  charges 
will  be  further  based  upon  the  type  of  service  required,  since  all  phases  of 
the  missions  do  not  require  the  entire  capability  of  the  leased  lines.  A 
further  division  of  the  $430  per  hour  fee  was  made  on  the  basis  of  bandwidth 
requirements  The  television  signal  requires  51  kilobits  per  second,  the 
telemetry  signals  require  16  kilobits  per  second,  the  tracking  and  command 
signals  require  2 kilobits  per  second  each  It  was  estimated  that  if  a charge 
were  made  on  the  basis  of  service  provided,  that  charge  would  be  approximately 
proportional  to  the  bandwidth  requirements  of  the  type  of  signal  being  pro- 
cessed. On  that  basis,  television  was  rated  at  $290  per  hour,  telemetry  was 
rated  at  $90  per  hour,  and  command  and  tracking  were  each  rated  at  $25  per 
hour.  Those  constants  were  utilized  in  arriving  at  the  network  rental 
calculations. 

The  mission  density  function  program  within  the  cost  analysis  programs  cal- 
culates the  number  of  hours  per  year  that  each  of  the  communications  services 
are  required,  based  upon  the  launch  schedule  and  mission  type  established  for 
that  year.  The  baseline  year  chosen  for  Tug  was  1984 

9 7 3.7  Space  Tug  Software  Maintenance 

A maintenance  and  support  cost  algorithm  has  been  developed  for  flight  soft- 
ware This  algorithm  assumes  that  the  four  baseline  programs  generated  in  the 
DDT&E  phase  will  not  be  subject  to  major  modifications  A major  modification, 
should  one  be  required,  is  to  be  costed  in  accordance  with  the  initial 
software  development  algorithm. 

The  maintenance  and  support  cost  algorithm  divides  the  level  of  effort 
requirements  into  manpower  required  to  design  the  changes,  manpower  required 
to  program  the  changes,  and  manpower  required  for  flight  program  verification 
For  programs  less  than  64,000  words  (instructions  and  data)  the  level  of 
effort  is  a function  of  the  number  of  programs  being  maintained  The  annual 
recurring  cost  for  this  service  is  $1,008  million  per  year  for  the 
flight  program  maintenance  efforts. 

9.7  3.8  Off-Peak  Manpower  Utilization 

Flight  control  and  flight  support  are  full-time  employment  for  those  personnel 
assigned  flight  control  and  flight  support  duties  There  will  be  no  multi- 
plexing between  operational  and  non-operational  assignments  The  time  during 
which  operations  are  not  in  progress  will  be  utilized  by  the  assigned  flight 
control  and  flight  support  personnel  in  preparation,  maintenance  and  other 
operations  related  activities.  The  frequency  and  complexity  of  Space  Tug  missions 
dictate  the  assignment  of  a dedicated  staff 
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9739  Summary  of  Recurring  Costs 

Table  9 7.3-1  presents  a summary  of  recurring  costs 


Table  9.73-1.  Total  Tug  Recurring  Cost  Summary 


El ement 

Dollars 

Facility  Maintenance 

19,672 

TOC  Software  Maintenance 

1,104,000 

Data  System  Maintenance 

134,458 

Sustaining  TOC  Engineering 

1,584,000 

Sustaining  TOC  Fit.  Control  Engineering 

1,440,000 

Network  Rental 

204,755 

Tug  Software  Maintenance 

] ,008,000 

TOTAL 

5,494,885 

974  Alternative  Concepts  Cost  Data 

Figure  9 7.4-1  defines  the  operational  concepts  analyzed  during  the  study  and 
the  application  of  the  concepts  to  the  IUS  and  Space  Tug  Programs 

Concept  1,  Separate  NASA/DoD  System,  is  in  accord  with  the  NASA  baseline  con- 
cept and  depicts  separate  NASA  and  DoD  control  center  development  to  satisfy 
their  respective  requirements  In  this  concept  control  center  hardware, 
software,  manpower  and  facilities  will  be  the  responsibil ityi  of  each  separate 
agency,  however,  it  does  not  preclude  the  potential  of  cost  savings  through 
the  development  of  similar  hardware  and  software 

Concept  2,  Shared  System,  defines  a single  Tug  Operations  Control  Center  for 
both  NASA  and  DoD  missions  Under  this  concept  each  agency  would  be  responsi- 
ble for  all  aspects  of  their  respective  missions  but  share  common  operational 
elements  Two  options  have  been  analyzed  under  this  concept,  (1)  2A  which 
assumes  NASA  in  a host  role  in  the  shared  center,  and  (2)  2B  assumes  DoD  in 
a host  role. 

9741  Level  II  Autonomy  - Concept  Development  Cost  Comparison 

Figure  9 7 4-2  presents  a comparison  of  NASA  and  DoD  expenses  for  a Level  II 
autonomy  Space  Tug  design  under  the  concepts 

1)  Separate  and  equal  NASA  and  DoD  operation 
2A)  Single  facility,  NASA  owned,  DoD  tenant 
2B)  Single  facility,  DoD  owned,  NASA  tenant 


Similarity  of  Concept  1 costs  derives  from  the  assumption  that  NASA  and  DoD 
operate  in  similar  modes,  and  the  DoD  costs  are  comparable  to  NASA  costs  for 
similar  functions 

The  shift  in  costs  to  increase  the  host's  net  outlay  in  Concepts  2A  and  2B 
does  not  preclude  recovery  of  some  portion  from  the  tenant,  but  does  assume 
the  host  will  retain  all  program  assests 
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TOTAL  ALTERNATIVE  DEVELOPMENT  COSTS 

ALTERN  ATIVE  1 ALTERNATIVE  2A  ALTERNATIVE  2 B 


ELEMEN T 

■ NASA 

DOD 

NAS  A 

DOD 

NASA 

DOD 

PHYSICAL  PLANT 

423620 

46  5 9 82 

563  414 

0 

0 

563523 

TOC  SOFTWARE  DEVELOPMEN T 

12262924 

12262924 

15040932 

773051 

87  56  0 5 

1 50  40932 

DATA  SYSTEM 

650961  8 

650961 8 

9764427 

0 

0 

97  6 4427 

OPERATIONS  STAFF  EQUIPMENT 

1120  80  0 

1232  880 

210710  4 

0 

0 

2129520 

TUG  SOFTWARE  DEVELOPMEN  T 

5 0 5 86  89 

50  5 86  89 

5 0 5 86  89 

50  5 86  89 

5 0 5 86  89 

50  5 86  e9 

TOTALS 

25375650 

25530092 

32534565 

5 83 1 7 3 9 

5934294 

32557090 

Figure  9.7.4-2.  Level  II  Autonomy  Concepts  Development  Cost  Comparison 


The  costs  presented  update  and  supercede  the  figures  presented  in  the  Space  Tug 
Baseline  Operations  Plan  {IBM  No  74W-0025)  dated  November,  1974  Cost  in- 
creases in  operational  hardware  and  flight  software  have  been  included 

9 7 4.2  Level  II  Autonomy  - Concept  Annual  Recurring  Cost  Comparison 

Figure  9.7  4-3  presents  a comparison  of  NASA  and  DoD  expenses  for  a Level  II 
autonomy  Space  Tug  design  under  the  concepts 

1)  Separate  and  equal  NASA  and  DoD  operation 
2A)  Single  facility,  NASA  owned,  DoD  tenant 
2B)  Single  facility,  DoD  owned,  NASA  tenant 

Similarity  of  Concept  1 costs  derives  from  the  assumption  that  NASA  and  DoD 
operate  in  similar  modes,  and  that  DoD  costs  are  comparable  to  NASA  costs 
for  similar  functions 

The  shift  in  costs  to  increase  the  host's  net  outlay  in  Concepts  2A  and  2B 
does  not  preclude  recovery  of  some  portion  from  the  tenant,  but  does  assume 
the  host  will  retain  all  program  assets  Tenant  income  and  tenant  fees  paid 
are  indicated. 

The  costs  presented  update  and  supercede  the  figure  presented  in  the  Space 
Tug  Baseline  Operations  Plan  (IBM  No.  74W-0025)  dated  November,  1974 

9.7  4 3 Level  III  Autonomy  - Concept  Development  Cost  Comparison 

Figure  9.7  4-4  presents  a comparison  of  NASA  and  DoD  expenses  for  a Level  III 
autonomy  Space  Tug  design  under  the  concepts 

1}  Separate  and  equal  NASA  and  DoD  operation 
2A)  Single  facility,  NASA  owned,  DoD  tenant 
2B)  Single  facility,  DoD  owned,  NASA  tenant 

Similarity  of  Concept  1 costs  derives  from  the  assumption  that  NASA  and  DoD 
operate  in  similar  modes,  and  that  DoD  costs  are  comparable  to  NASA  costs 
for  similar  functions 

The  shift  in  costs  to  increase  the  host's  net  outlay  in  Concepts  2A  and  2B 
does  not  preclude  recovery  fo  some  portion  from  the  tenant,  but  does  assume 
that  host  will  retain  all  program  assets 

The  costs  presented  update  and  supercede  the  figures  presented  in  the  Space 
Tug  Baseline  Operations  Plan  (IBM  No.  74W-0025)  dated  November,  1974.  Cost 
increases  in  operational  hardware  and  flight  software  have  been  included. 

9.7  4.4  Level  III  Autonomy  - Concept  Annual  Recurring  Cost  Comparison 

Figure  9 7 4-5  presents  a comparison  of  NASA  and  DoD  expenses  for  a Level  III 
autonomy  Space  Tug  design  under  the  concepts 

1)  Separate  and  equal  NASA  and  DoD  operation 
2A)  Single  facility,  NASA  owned,  DoD  tenant 
2B)  Single  facility,  DoD  owned,  NASA  tenant 
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LEVEL  II  AUTONOMY  CONCEPT  ANNUAL  RECURRING  COST  COMPARISON 


CONCEPT  2A 


CONCEPT  2B 


TOTAL  ALTERNATIVE  RECURRING  COSTS 


ALTSRHAUVS  1 ALTTtV  A'TVF  i/i  ALTERNATIVE  28 


ELEMEN  T 

I ASA 

D (D 

IAS  A 

DCD 

* ASA 

DCO 

FACILITY  MAINTENANCE 

20072 

22079 

26696 

0 

0 

2 eioi 

TOC  SOFTWARE  MAINTENANCE 

1104000 

1104000 

13910  40 

0 

0 

1391040 

DATA  SI  STEM  MAIN  TEN  Al>  CS 

134  45  8 

13445  8 

'’Oie  87 

0 

0 

2016  87 

SUSTAINING  TOC  ENGINEERING 

2Q1 60QO 

J794240 

2913120 

0 

0 

2 £02240 

SUSTAINING  TOC  FIT  CN  TL  ENGINEERING 

1920000 

170  8800 

277  4 400 

0 

0 

266  8800 

NETWORK  RENTAL 

212772 

212772 

212772 

°1 277  2 

21  772 

212772 

TUG  SOFTWARE  MAINTENANCE 

loo  eooo 

100  800  0 

100  8000 

100  8000 

100  BQOO 

looeooo 

TOTALS 

6 LI  5302 

59  843  49 

8S27714 

1220772 

1220772 

8312639 

DOD  TENANT  COSTS  ALTERNATIVE  2A 


E IEMBS  T 

SERVICE  FEES 

FACI  LITY  M AIR  TEN  Alt  CE 

TOC  S CF  TV  ARE  H AIN  TEN  AN  CE 

DATA  SYSTEM  MAIN  TEN  AN  CE 

SUSTAINING  TOC  ENGINEERING 

SUSTAINING  TOC  FIT  QtTL  ENGINEERING 

NE'VORK  RENTAL 

JVG  SOFTWARE  MAINTENANCE 

RENTAL  FEES 

P^SICAL 

data  system 

OPERATIONS  STAFF  EQUIPMENT 

TOTAL 


COST  PER  YEAR 

6624 
2 87040 
67229 
69“  120 
e5  4U00 
0 
0 

15  969 
UOG  651 
1232  80 
265  8521 


NASA  TENANT  COSTS  ALTERNATIVE  2B 


ELEMEN T 

SERVICE  FEES 

FACILITY  MAIN  TEN  CtCE 

TOC  SC* TV  HRS  MAIN  SFN pJt  CF 

DATA  SYSTEM  M Alt  TEl  ANCE 

SUSTAItING  TOC  ENGINEERING 

SUS  TAINING  TOC  F L?  O TL  ENGINEERING 

NETWORK  RENTAL 

T VG  SOFTWARE  MAIN  TEN  «/  CE 

RENTAL  FEES 

PHYSICAL  PLANT 

SATA  Si  STEM 

OPERATIONS  5T/1FF  EQUIPME17 

TOTAL 


COS  T PER  YEAR 

6022 
2 8?  0 40 

67229 
1 0 0 80  0 0 
960000 
0 
0 


1451  B 
405  851 
112080 
2 661739 


Figure  9743  Level  I I Autonomy  Concept  Annual  Recurring  Cost  Comparison 
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TOTAL  ALTERNATIVE  DEVELOPMENT  COSTS 


ELEMENT 
PHYSICAL  PLANT 
TOC  SOFTWARE  DEVELOPMENT 
DATA  SYSTEM 

OPERATIONS  STAFF  EQUIPMENT 
TUG  SOFTWARE  DEVELOPMEN  T 

TOTALS 


ALTERS  ATIVE  1 
NASA  DOD 

423620  465  892 

15559751  15559751 
7015618  7015618 

1120  800  1232  880 

47  57  90  2 47  57  90  2 

28  87  7690  290320  42 


ALTERNATIVE  2 A 
NASA  DOD 

563  41  4 0 

193  807  83  157  8037 

10523427  0 

2107104  0 

47  57902  47  57902 

37305630  6335939 


ALTERNATIVE  2 B 
NASA  DOD 
0 563523 

17  80921  193  807  83 
0 10523427 
0 2129520 

U757902  47  57902 

653  8 82  3 37  355155 


Figure  9J.4-4  Level  III  Autonomy  Concept  Development  Cost  Comparison 


TOTAL  ALTERNATIVE  RECURRING  COSTS 

AL1SH NATIVE  1 ALTER}} A THE  2A  ALTEP  IATIVE  28 


ELEMENT 

NASA 

DOD 

NASA 

D W 

NASA 

DOD 

FACILITY  MAINTENANCE 

2007  2 

22079 

26696 

0 

0 

2 6101 

TGC  SOFTWARE  MAIL  TEN  /V  CE 

1296000 

1296000 

1632960 

0 

0 

1632960 

DATA  Si  STEM  MAIN  TEN  AN  CE 

13  6795 

13  9795 

20  8192 

0 

0 

20  8192 

SUSTAINING  TOC  ENGINEERING 

2016000 

1794240 

2913120 

0 

0 

2 8022  40 

SUSTAINING  TOC  FLT  CNTL  ENGINEERING 

1920000 

1708800 

2774400 

0 

0 

2668800 

NETWORK  RENTAL 

*1 2?  7 2 

212772 

212772 

212772 

212772 

212772 

TUG  S OF  TV  ARE  N AIN  7ENAV  CE 

100  8000- 

1008000 

1 00  8000 

100  80  00 

100  8000 

100-8000 

TOTALS 

661163  8 

61  806  86 

8776140 

1220772 

1220772 

8561065 

NASA  TENANT  COSTS  ALTERNATIVE  2 A 


DOD  TENANT  COSTS  ALTERNATIVE  2 A 


SLEMEH T 

SERVrCS  FEES 

FACILITY  H MUTE# MCE 

TOC  SOFTWARE  MAINTEI  MCE 
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Figure  9 7 4-5  Level  III  Autonomy  Concept  Annual  Recurring  Cost  Comparison 


Similarity  of  Concept  1 costs  derives  from  the  assumption  that  NASA  and  DoD 
operate  in  similar  modes,  and  that  DoD  costs  are  comparable  to  NASA  costs  for 
similar  functions 

The  shift  in  costs  to  increase  the  host's  net  outlay  in  Concepts  2A  and  2B 
does  not  preclude  recovery  of  some  portion  from  the  tenant,  but  does  assume 
the  host  will  retain  all  program  assts  Tenant  income  and  tenant  fees  paid 
are  indicated 

The  costs  presented  update  and  supercede  the  figures  presented  in  the  Space 
Tug  Baseline  Operations  Plan  {IBM  No.  74W-0025)  dated  November,- 1974 

9.7.5  Rationale  for  Selection  of  Concept  1,  Level  II 

Concept  1 was  chosen  as  most  likely  to  be  implemented  on  the  basis  that  sharing 
of  a real-time  operational  facility  between  agencies  having  dissimilar  security 
requirements  would  be  unworkable  over  a program  of  10  years  duration 

Level  II  autonomy  was  selected  because  the  higher  autonomy  space  vehicle  h,as 
the  potential  to  reduce  ground  support  below  the  current  calculated  minimum 
A high  autonomy  Space  Tug  is  technically  feasible  with  no  advance  in  the 
state-of-the-art 

The  technique  used  to  establish  the  above  conclusions  is  an  adaptation  of  the 
Kepner-Tregoe  Decision  Analysis  methodology  to  the  parameters  of  the  Tug 
program. 

Six  objectives  were  established.  An  objective,  in  Kepner-Tregoe  context,  is 
a factor  or  consideration  to  be  optimized  Differing  implementations,  or 
"Alternatives"  have  differing  impacts  upon  the  objectives.  In  order  to 
quantify  these  impacts  and  place  the  values  of  the  objectives  into  perspective, 
each  objective  is  given  a "Rank",  which  is  a numerical  weight  between  1 and 
10  establishing  the  relative  importance  of  the  objective 

The  impact  of  each  alternative  is  established  by  analysis  of  the  alternative 
and  the  estimation  of  the  effect  on  the  objective,  a number  between  0 and  10 
In  assessing  the  impact  of  alternatives,  the  sense  of  the  assessing  is  that 
numerical  value  increases  as  "desirability"  increases.  For  example,  cost  is 
an  objective  which  is  inversely  related  to  desirability.  Thus,  higher  cost 
results  in  a lower  numerical  value 

Once  the  impact  of  each  alternative  on  each  objective  is  established,  a 
computer  program  performs  the  computations  required  to  establish  a final 
relative  ranking  of  the  alternatives. 

The  process  is  identical  for  establishing  the  undesirable  attributes  of  each 
alternative.  The  final  results  are  obtained  by  weighting  the  finishing  order 
of  desirable  and  undesirable  alternatives  and  selecting  the  best  composite 
alternative. 

Three  experienced  mission  operations  engineers  were  given  the  task  of  establish- 
ing the  impact  of  the  Space  Tug  alternatives  on  a fixed  set  of  objectives 
and  adverse  consequences.  Figure  9. 7.5-1  illustrates  the  Kepner-Tregoe  input 
sheet. 
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• INPUT  DATA  FROM  3 EXPERIENCED  ENGINEERS 

• WEIGHTED  (+5  TO -5)  INDIVIDUAL  SELECTIONS 

• NUMERICAL  SUM  OF  FACTORS/CONCEPT 

• SELECTED  "BEST  SCORE"  CANDIDATE 


Figure  9 7 5-1  Space  Tug  Concept  Trade 


Table  9 7 5-1  (a)  presents  the  summary  results  of  the  three  inputs  after 
computation  and  rank-ordering.  The  first  column  of  Table  9.7  5-1  (a)  is  the 
weighting  factor  for  rank-order  This  is  used  to  further  drive  apart  the 
finishing  position  of  each  alternative.  Table  9 7 5-1  (b)  is  the  final  weight- 
ing matrix.  The  weighting  factor  of  Table  9 7 5-1  (a)  is  multiplied  by  the 
number  of  times  the  alternative  appears  in  the  row  relative  to  the  weighting 
factor  Thus,  since  alternative  1 appears  four  times  in  the  row  having  a weight- 
ing factor  of  5,  it  is  given  a score  of  20  in  column  one  of  Table  9.7  5-1  (b) 

When  that  operation  is  completed,  the  columns  are  summed  to  give  the  final 
selection 

The  Space  Tug  alternative  scoring  highest  was  Level  II  autonomy  - Concept  1, 
with  Level  I I I/Concept  1 and  Level  I I/Concept  2B  ranked  second  and  third, 
respectively  This  leads  to  the  conclusion  that,  based  upon  the  objectives  and 
adverse  factors  analyzed.  Level  II  autonomy  - Concept  1 implementation  is  the 
best  selection  for  Space  Tug 
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Table  9. 7 5- 1.  Kepner - Trego  e Results 
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1 = LEVEL  II/CONCEPT  1 (24) 

2 = LEVEL  I II/CONCEPT  1 (12) 

3 = LEVEL  II/CONCEPT  2B  (8) 


IUS/SPACE  TUG  OPERATIONS  TRANSITION 


This  section  develops  the  rationale  for  and  presents  the  recommended 
mode  of  transitioning  from  IUS  operations  to  Space  Tug  operations.  The 
IUS  operations  concept  is  summarized  in  terms  of  the  developmental  work 
breakdown  structure  (XXX-WBS)  and  compared  to  the  equivalent  Space  Tug 
work  breakdown  structure  (320-WBS).  This  comparison  categorizes  the 
WBS  elements  onto  four  groups 

Common  to  XXX-WBS  and  320-WBS 
Unique  to  XXX-WBS 
Unique  to  320-WBS 

Modifiable  from  XXX-WBS  to  320-WBS 

After  the  groups  are  identified,  the  XXX-WBS  and  320-WBS  are  combined  into 
a master  IUS/Tug  mission  operations  development  plan.  This  integrated 
plan  is  supported  by  a composite  work  breakdown  structure,  program  plan 
bar-chart,  a manpower  estimate  covering  the  first  five  years,  and  a PERT 
chart  of  the  composite  activities. 

10  1 DEFINITION  OF  FLIGHT  CONTROL  OPERATIONAL  ELEMENTS 

This  section  summarizes  the  operational  support  elements  (XXX-WBS) 
developed  for  the  Expendable  Interim  Upper  Stage  in  Volume  II  of  this 
report,  and  the  Space  Tug  Operational  Elements  (320-WBS)  developed  in 
this  volume. 

10  1 1 IUS  Work  Breakdown  Structure 

Table  10  1 1-1  presents  the  IUS  work  breakdown  structure  The  "XXX"  desin- 
nates  a three  digit  program  identifier  which  NASA  will  supply  when  the  IUS 
achieves  full  program  status 

Portions  of  the  IUS  WBS  dictionary  have  been  extracted  from  Volume  II  and 
are  presented  in  Table  10.1.1-2  The  complete  WBS  heirarchy  is  not  shown, 
since  comparisons  with  the  similar  elements  of  the  Space  Tug  WBS  must  be 
made  at  the  lowest  level  of  detail,  i e , where  a "product"  is  developed. 
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Table  10  1 7-7.  IUS  MBS  Identification  Number  Sequence 


IDENTIFICATION  NUMBER 

XXX 
XXX-01 
XXX-01-01 
XXX-01-01 -01 
XXX-01 -01 -02 

XXX-01 -02 
XXX-01-02-01 
XXX-01 -02-01 -01 
XXX-01 -02-01 -02 
XXX-01 -02-01 -03 
XXX-01 -02-01 -04 
XXX-01-02-01 -05 
XXX-01-02-01-06 
XXX-01 -02-01 -07 
XXX-01-02-01 -08 
XXX-01 -02-02 
XXX-01 -02-03 
XXX-01-02-04 
XXX-01 -03 
XXX-02 
XXX-02-01 
XXX-02— 01 -01 
XXX-02-01 -02 
XXX-02-01-03 
XXX-02-02 
XXX-02-03 
XXX-02-04 
XXX-02-04-01 
XXX-02-04-01-01 
XXX-02-04-01 -02 
XXX-02-04-01-03 
XXX-02-04-01 -04 

XXX-02-04-01 -05 

XXX-02-04-02 

XXX-02-04-02-01 

-XXX-02-04-03 

XXX-02-04-03-01 

XXX-02-04-03-02 

XXX-02-04-05 

XXX-02-04-05-01 

XXX-03 

XXX-05 

XXX-05-01 

XXX-05-02 


ELEMENT  LEVEL 

IUS  PROJECT 
Project  Management 
Cost/Performance  Management 
Cost  Control  System 
Schedule  Control  System 
Project  Direction 
Development  Management 
Contract  Software  Development 
Plan  Facility  Utilization 
Computer  Utilization  Plan 
Maintenance  Schedule 
Hire  Control  and  Support  Staff 
Obtain  IUS  System  Characteristics 
Prepare  IUS  Interagency  Documents 
IUS  Interagency  Coordination 
Quality  Management 
Logistics  Management 
Engineering  Administration 
Information  Management 
Systems  Engineering 
IUS  Systems  Engineering 
Master  Launch  Schedule  Analysis 
IUS  Mission  Characterization 
Determine  IUS  Failure  Modes 
Shuttle  Interface 
Payload  Interface 
Sustaining  Engineering 
Flight  Control  Engineering 
Mission  Phase  Manning  Requirements 
IUS  Console  Position  Guidelines 
Define  IUS  Operator  Certification/Criteria 
Validation  Test  Requirements-Fundamental 
IUS  Ground  Programs 

IUS  Ground  Validation  Test  Requirements 
Flight  Support  Engineering 
Select  Operational  Data  System 
Mission  Engineering 

IUS  Mission  Planning  and  Optimization 
IUS  Abort  Planning 
Mission  Evaluation  Engineering 
IUS  Post  Mission  Reports 
IUS  Vehicle  Main  Stage 
Logistics 

Transportation  and  Handling 
Training 


10-2 


Table  10.1.1-1.  /US  WBS  Identification  Number  Sequence  (Continued) 


IDENTIFICATION  NUMBER 

XXX-05-02-01 

XXX-05-02-02 

XXX-05-02-03 

XXX-05-02-03-01 

XXX-05-02-03-02 

XXX-05-02-03-03 

XXX-05-02-03-04 

XXX-05-02-03-05 

XXX-06 

XXX-06-01 

XXX-06-02 

XXX-06-03 

XXX-06-04 

XXX-06-05 

XXX-06-06 

XXX-06-06-01 

XXX-06-06-02 

XXX-07 

XXX-07-01 

XXX-07-02 

XXX-07-03 

XXX-07-04 

XXX-07-04-01 

XXX-07-04-02 

XXX-08 

XXX- 09 

XXX- 10 

XXX-10-01 

XXX-10-01-01 

XXX-10-01 -02 

XXX-10-01 -03 

XXX-10-01 -04 

XXX-10-01 -04-01 

XXX-10-01-04-02 

XXX-10-01 -05 

XXX-10-01 -05-01 

XXX-10-01-05-02 

XXX-10-01 -05-03 

XXX-10-01 -05-04 

XXX-10-02 

XXX- 1 0-02-01 

XXX-10-02-02 

XXX-10-02-03 

XXX-10-03 

XXX-10-03-01 

XXX-10-03-02 

XXX-10-04 

XXX- 11 


ELEMENT  LEVEL 

Simulators  and  Equipment 
Ground  Crew  Training 
Flight  Operations  Crew  Training 
IUS  Training  Requirement/Criteria/Simsked 
Develop  IUS  Training  Material 
Design  IUS  Mission  Simulation 
IUS  Classroom  Training 
IUS  Mission  Simulation  Training 
Facil ities 
Manufacturing 
Test 

Maintenance  and  Refurbishment 
ETR  Launch 
WTR  Launch 

Flight  Operations  Facility 
Size  Facility/Design  Physical  Plant 
Construct  Physical  Plant 
Ground  Support  Equipment  (GSE) 

Manufacturing  and  Test  GSE 
Eastern  Test  Range  GSE 
Western  Test  Range  GSE 
Flight  Operations  GSE 
Install  Operational  Data  System 
Install  Operational  Consoles/Hardware 
Vehicle  Test 
Launch  Operations 
Flight  Operations 

Mission  Planning  and  Documentation 
Develop  IUS  Procedures  and  Rules 
IUS  Mission  Failure  Effects 
Analyze  IUS  Component  Characteristics 
Flight  Control  Systems  Handbook 
Prepare  IUS  Systems  Handbook 
Publish/Update  IUS  Systems  Handbook 
IUS  Network  Interface  Documentation 
Define  Network  Tracking  Requirements 
Network  Tracking  Validation  Procedures 
IUS  Network  Data  Handling  Requirements 
IUS  Network  Data  Validation  Procedures 
Operational  Preparations 

Design  Network  Interface  System 
Console  Organization 
IUS  Display  Format  Design 
Mission  Readiness  Testing 
Network  Tracking  Validation  Tests 
IUS  Network  Validation  Tests 
Conduct  IUS  Mission  Operations 
Refurbishment  and  Integration 
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Table  10.1 1-1  /US  WBS  Identification  Number  Sequence  (Continued) 


IDENTIFICATION  NUMBER 

ELEMENT 

LEVEL 

XXX- 15 

Software 

4 

XXX-15-01 

Flight  Software 

5 

XXX-15-01-01 

Plan  Flight  Software  Development 

6 

XXX-15-01 -02 

Baseline  Flight  Program  Development 

6 

XXX-15-01 -02-01 

EDD  - IUS  Flight  Program 

7 

XXX-15-01 -02-02 

Program  IUS  Flight  Software 

7 

XXX-15-01-02-03 

IUS  Flight  Program  Verification 

7 

XXX— 1 5-01-03 

Mission  Specific  Program  f'iodifi cation 

6 

XXX-15-01 -03-01 

IUS  Mission  Specific  EDD 

7 

XXX-15-01 -03-02 

IUS  Mission  Specific  Program 

7 

XXX-1 5-01-03-03 

IUS  Mission  Program  Verification 

7 

XXX-1 5-02 

Ground  Software 

5 

XXX-1 5-02-01 

Plan  Ground  Software  Development 

6 

XXX-15-02-02 

Equation  Definition 

6 

XXX-1 5-02-02-01 

EDD  - Executi ve/Tracking/Planmng 

7 

XXX-1 5-02-02-02 

EDD  - IUS  Dndata/Updata/Sim 

7 

XXX- 1 5-02-03 

Programmi ng 

6 

XXX-1 5-02-03-01 

Program  Ground  EX/TK/Planmng  SW 

7 

XXX-15-02-03-02 

Program  IUS  Dndata/Updata/Sim 

7 

XXX-1 5-02-04 

Program  Verification 

6 

XXX-1 5-02-04-01 

Verify  Executi ve/TK/Pl anmng  SW 

7 

XXX-1 5-02-04-02 

Verify  IUS  Dndata/Updata/Sim 

7 

XXX-1 5-02-05 

Mission  Specific  Simulation 

6 

XXX- 15-02-05-01 

Program  IUS  Mission  Simulation 

7 

XXX— 1 5-03 

Computer  Selection  Support 

5 

XXX-1 5-03-01 

Estimate  Ground  Software  Size 

6 

XXX-1 6 

Orbiter  Interface 

4 
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Table  10  1 1-2  I US  Operational  Element  Dictionary 


XXX-02-01-01  MASTER  LAUNCH  SCHEDULE  ANALYSIS 

The  master  Launch  Schedule  will  be  analyzed  to  determine  the  type,  spacing, 
and  frequency  of  IUS  flights.  This  task  will  establish  the  range  of  mission 
types,  trajectories,  payload  accommodations  and  control  facility  utilization 
requirements  across  the  IUS  operational  period.  This  task  is  a predecessor 
to  the  establishment  of  IUS  mission  characteristics  and  control  facility 
utilization  planning. 

XXX-01 -02—01 -01  CONTRACT  SOFTWARE  DEVELOPMENT 

This  task  includes  all  effort  necessary  to  prepare  a Statement  of  Work, 
evaluate  proposals  and  provide  financial,  contracting  and  procurement 
support  in  order  to  place  an  outside  contractor  under  contract  for 
development  of  ground  and  flight  software. 

XXX-01 -02-01—02  PLAN  FACILITY  UTILIZATION 

This  task  includes  all  efforts  involved  in  establishing  a coherent  plan 
for  the  utilization  of  a Mission  Control  facility  This  will  include 
such  things  as  scheduling  of  activities,  program  sharing,  office,  canteen, 
technical  support  area  and  other  generic  requirements  which  impact 
facility  design. 

XXX— 1 5-01 -01  PLAN  FLIGHT  SOFTWARE  DEVELOPMENT 

This  task  includes  all  efforts  required  to  establish  a schedule  for 
development  of  the  flight  software,  establish  design  concept  validation 
procedures,  establish  the  necessity  for,  and  required  characteristics  of, 
hybrid  and  interpretive  simulators,  and  establishing  controls  and  feedback 
to  insure  customer  requirements  on  the  IUS  flight  software  are  fulfilled 

XXX-1 5-02-01  PLAN  GROUND  SOFTWARE  DEVELOPMENT 

This  task  includes  all  efforts  necessary  to  establish  a plan  for  the 
development  of  IUS  ground  support  software.  Included  will  be  the 
advisability  of  transforming  software  modules  from  existing  ground  control 
systems,  establishment  of  the  basic  data  processing  techniques,  planning 
the  use  of  existing  ground  system  simulators,  and  establishing  ground 
program  organization  and  source  strings. 

XXX-02-04-01-01  MISSION  PHASE  MANNING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  types  and  quantity 
of  personnel  required  to  support  IUS  flight  control  and  flight  support 
activities.  It  will  include  an  analysis  of  the  mission  density,  the 
overlap  between  adjacent  modules  in  the  mission  structure  and  will  establish 
the  control  and  support  personnel  necessary  to  accomplish  the  IUS  missions 
with  a minimum  loss  of  productive  man  hours. 
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Table  10  1 1-2  /US  Operational  Element  Dictionary  (Continued) 


XXX-01 -02-01 -03  COMPUTER  UTILIZATION  PLAN 

This  task  includes  all  efforts  required  to  develop  and  enforce  a plan  to 
maximize  the  utilization  of  the  computational  facility  incorporated  in  the 
IUS  ground  control  complex.  This  will  include  a pre-emption  hierarchy, 
mission  planning  schedule,  mission  operation  schedule,  batch  processing 
schedule,  etc 

XXX-01 -02-01 -04  MAINTENANCE  SCHEDULE 

This  task  establishes  the  housekeeping  and  periodic  maintenance  require- 
ments of  the  control  center  and  associated  equipments  This  task  includes 
the  contracting  for,  and  administration  of,  specific  external  maintenance 
of  the  data  system,  plant  environmental  control  mechanisms,  and  janitorial 
services.  Periodic  and  specific  maintenance  of  the  flight  control  and 
flight  support  console  items  will  be  conducted  by  the  permanent  party 
flight  support  staff. 

XXX-01-02-01-05  HIRE  CONTROL  AND  SUPPORT  STAFF 

This  task  includes  all  efforts  required  to  procure  competent  personnel  to 
perform  flight  control  tasks  in  the  technical  disciplines  of  propulsion, 
avionics,  networks,  communication,  guidance,  dynamics  and  data  selection 
It  also  includes  the  efforts  required  to  hire  flight  support  personnel 
in  the  technical  disciplines  of  facility  supervisor,  data  systems,  mamtenace 
operations  and  software  support. 

XXX-10-02-02  CONSOLE  ORGANIZATION 

This  task  includes  all  efforts  necessary  to  establish  the  requirements 
for  location  of  console  display  and  control  devices  to  the  satisfaction 
of  the  console  operating  personnel. 

XXX-10-02-01  DESIGN  NETWORK  INTERFACE 

This  task  includes  the  engineering  effort  necessary  to  establish  the 
interface  with  the  data  acquisition  network.  It  specifically  includes 
telemetry  decommutation  and  special  processing,  command  processing  and 
tracking  format  and  processing  requirements  The  output  of  this  task 
will  be  the  operational  requirements  for  a network  interface  systems 
design  which  will  include  suggested  hardware  items. 

XXX-1 5-03-01  ESTIMATE  GROUND  SOFTWARE  SIZE 

This  task  analyzes  the  equation  defining  document  for  ground  software  and 
establishes  a lower  boundary  upon  the  data  system  memory  size  and  central 
processor  unit  speed  requirements.  For  maximum  cost-effectiveness  this 
task  must  be  completed  prior  to  the  selection  of  an  operational  data 
system. 
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Table  10  1 1-2  /US  Operational  Element  Dictionary  (Continued) 


XXX-02-04-02-01  SELECT  OPERATIONAL  DATA  SYSTEM 

This  task  includes  all  efforts  required  to  establish  the  integrated 
requirements  of  an  operational  data  system  and  takes  into  account  the 
ground  software  size  estimate,  the  computer  utilization  plan,  and 
growth  factors.  This  task  also  includes  all  procurement  and  purchase 
operations  necessary  in  the  buy  of  an  operational  data  system,  and  the 
engineering  of  the  data  system  configuration. 

XXX-07-04-01  INSTALL  OPERATIONAL  DATA  SYSTEM 

This  task  includes  all  efforts  by  the  data  system  contractor  to  install, 
diagnose  and  checkout  the  completed  system  installation.  At  the  end  of 
this  task,  the  data  processing  system  will  be  on-line  and  operational 
ready  to  support  future  data  processing  activities. 

XXX-06-06-01  SIZE  FACILITY/DESIGN  PHYSICAL  PLANT 

Prior  to  beginning  this  task,  the  operational  data  system  will  have  been 
selected,  the  network  interface  design  will  have  been  completed  and 
equipment  selected,  and  the  console  equipment  designed  and  ordered.  This 
task  includes  the  architectural  design  of  the  facility. 

XXX-06-06-02  CONSTRUCT  PHYSICAL  PLANT 

This  task  includes  the  efforts  involved  by  a building  contractor  to  perform 
site  preparation,  construction  of  a physical  plant,  environmental  control 
and  electrical  installations  on  the  structure. 

XXX-07-04-02  INSTALL  OPERATIONAL  CONSOLES 

This  task  includes  the  installation  of  the  console  hardware  and  associated 
interface  equipments.  This  task  presumes  that  the  consoles  will  be 
delivered  to  the  finished  physical  plant  by  a vendor  and  then  will  be 
installed  by  flight  support  technicians. 

XXX-15-02-02-01  EQUATION  DEFINING  DOCUMENT  - EXECUTIVE/TRACKING/PLANNING 
SOFTWARE 

This  task  includes  those  efforts  in  the  definition  and  analysis  leading 
to  the  development  of  the  equations  and  algorithms  to  be  utilized  in 
the  fundamental  IUS  ground  programs. 

XXX-02-04-01-04  VALIDATION  TEST  REQUIREMENTS  - FUNDAMENTAL  IUS  GROUND 
PROGRAMS 

This  task  includes  the  establishment  of  proof-of-performance  parameters 
for  the  software  which  is  fundamental  to  the  IUS  ground  operations.  This 
task  establishes  the  vital  criteria  against  which  the  program  performance 
is  to  be  evaluated,  and  should  be  conducted  independently  of  the  Equation 
Definition  generation. 


Table  10  1 1-2  IUS  Operational  Element  Dictionary  (Continued) 


XXX- 1 0-01 -05-01  DEFINE  GROUND  NETWORK  TRACKING  REQUIREMENTS 

This  task  includes  all  efforts  necessary  to  determine  the  required  accuracy 
of  the  tracking  network  The  output  of  this  task  will  be  utilized  to 
establish  performance  requirements  on  the  network,  which  will  be 
administered  by  an  agency  other  than  the  Mission  Control  NASA  Center 

XYX-10-01 -05-02  NETWQPK  TRACKING  VALIDATION  PROCEDURES 

This  task  includes  those  systems  analyses,  mission  engineering,  flight  control 
and  flight  support  efforts  required  to  develop  a checkout  procedure  which 
will  exercise  the  tracking  capabilities  of  the  support  network  from  the 
flight  control  and  flight  support  consoles  in  the  Mission  Control  Center 
The  output  of  this  task  will  be  a procedural  checklist  which  will  be  followed 
in  the  actual  testing  of  the  network  proof-of-performance 

XXX-1 0-03-01  NETWORK  TRACKING  VALIDATION  TESTS 

This  task  includes  all  efforts  required  to  set  up  and  conduct  specific 
premission  tests  of  the  tracking  capabilities  and  tracking  accuracies  of 
the  support  network  This  will  involve  the  generation  of  tapes  to  simulate 
IUS  vehicles  and  ground  receiving  tracking  stations,  the  distribution  and 
execution  of  procedures  previously  prepared  and  the  evaluation  of  test 
results. 

XXX-15-02-03-01  PROGRAM  GROUND  TRACKING,  PLANNING  AND  EXECUTIVE  ROUTINES 

This  task  depends  on  the  generation  of  an  adequate  Equation  Defining  Document 
at  a prior  time,  and  includes  the  programming  of  all  fundamental  routines 

XXX-1 5-02-04-01  VERIFY  EXECUTIVE  TRACKING  AND  PLANNING  SOFTWARE 

This  task  verifies  that  the  intent  of  the  Equation  Defining  Document  has  been 
implemented  in  the  developed  programs  by  testing  the  coded  program  under 
critical  operational  situations  and  includes  the  development  of  any  special 
tools  or  simulators  necessary  in  the  accomplishment  of  this  task 

XXX-01 -02-01 -06  OBTAIN  IUS  SYSTEM  CHARACTERISTICS 

This  task  includes  all  efforts  necessary  to  acquire,  catalog,  define  and 
analyze  the  operational  characteristics  of  the  IUS  system  The  output  of 
this  task  is  utilized  in  the  development  of  flight  controller  display 
designs,  network  telemetry  and  update  interface  system  design  and  as 
primary  input  into  the  determination  of  operational  failure  modes 

XXX-02-01-02  IUS  MISSION  CHARACTERIZATION 

This  task  accepts  the  output  of  the  master  launch  schedule  analysis  task 
and  operates  on  that  output  to  determine  the  specific  characteristics  of 
all  defined  IUS  missions.  The  output  of  this  task  is  utilized  in  the 
determination  of  mission  phase  manning  requirements,  definition  of  IUS 
operator  certification  (and  criteria  for  certification),  a computer 
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Table  10  1 1-2  /US  Operational  Element  Dictionary  ( Continued) 


utilization  plan  for  the  IUS  portion  of  the  Shuttle  era  and  the  associated 
maintenance  schedule 

XXX-15-01-02-01  EQUATION  DEFINING  DOCUMENT  - IUS  FLIGHT  PROGRAM 

This  task  includes  basic  conceptual  work  on  the  requirements  for  flight 
software,  customer  support  and  flight  software  definition,  definitions  of 
equations  pertaining  to  vehicle  dynamics,  a design  of  algorithm  techniques 
and  the  associated  simulation  equipments,  the  generation  of  a program 
requirements  document  known  as  the  Equation  Defining  Document  (EDD), 
control  of  requirements,  performance  of  software  implementation  studies, 
analysis  of  sample  calculations,  definition  of  flight  control  functional 
interfaces,  definition  of  hardware  interfaces,  and  miscellaneous  preliminary 
analysis. 

XXX- 1 5-02-02-02  IUS  DOWN  DATA,  UP  DATA  AND  SIMULATION  GROUND  SOFTWARE 

This  task  includes  all  efforts  required  to  create  an  Equation  Defining 
Document  (EDD)  for  those  ground  software  modules  which  are  specifically 
oriented  to  the  IUS.  The  output  of  this  task  is  an  Equation  Defining 
Document  against  which  the  ground  IUS-peculiar  software  will  be  programmed. 

XXX-02-04-01-05  IUS  GROUND  VALIDATION  TEST  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  criteria  for 
acceptance  or  rejection  of  IUS-peculiar  ground  software.  This  task  is 
performed  independently  of  the  programming  effort  and  is  specifically  to 
establish  proof- of- performance  standards  against  which  the  program  will 
be  judged. 

XXX-02-01-03  DETERMINE  IUS  FAILURE  MODES 

After  the  IUS  system  characteristics  have  been  obtained,  categorized  and 
defined,  the  systems  will  be  analyzed  for  high-probability  failure  modes. 

The  output  of  this  task  will  be  a list  of  potential  failures  which  can 
impact  the  operational  performance  of  the  vehicle.  Failures  of  a cosmetic 
nature  will  not  be  considered.  The  output  of  this  task  is  a list  of  high 
probability  failure  modes  which  will  then  be  analyzed  for  the  overall 
mission  effect  of  that  failure. 

XXX- 1 0-02-03  IUS  DISPLAY  FORMAT  DESIGN 

This  task  includes  all  efforts  required  to  establish  the  organization, 
display  format  and  engineering  units  for  flight  control  and  flight  support 
personnel  digital  TV  presentation.  This  task  also  includes  all  efforts 
directed  toward  the  definition  of  the  special  processing  requirements, 
remote  site  and  control  center  logical  operations,  limit  sensing,  event 
light  triggering,  etc. 
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XXX-10-01-02  IUS  MISSION  FAILURE  EFFECTS  ANALYSIS 

Once  the  IUS  failure  modes  have  been  identified  and  categorized,  the 
occurance  of  these  failures  at  various  points  in  the  flight  must  be  evaluated 
for  overall  mission  effect.  The  output  of  this  task  will  be  a series  of 
scenarios  against  which  pre-thought  decisions  may  be  constructed 

XXX-05-02-03-03  DESIGN  IUS  MISSION  SIMULATION 


This  task  includes  all  efforts  required  to  integrate  the  results  of  the 
IUS  procedures  and  rules,  the  optimum  and  abort  mission  timelines,  and 
operator  training  criteria  into  an  IUS  mission  specific  simulation  design 
This  task  will  be  accomplished  both  in  the  DDT&E  phase  and  in  the  recurring 
phase  of  the  IUS  program  A specific  simulation  design  will  be  formulated 
for  each  mission  The  flight  controller  and  flight  support  personnel  will 
be  trained  against  the  mission  specific  simulation  in  preparation  for  their 
operational  roles.  The  output  of  this  task  is  a set  of  malfunctions,  pre- 
dicted responses  and  operator  performance  evaluation  criteria. 

XXX- 10-01 -03  ANALYZE  IUS  COMPONENT  CHARACTERISTICS 

This  task  includes  all  efforts  required  to  assemble  basic  operational 
information  describing  the  characteristics  of  the  operationally  significant 
components  of  the  IUS  vehicle  The  output  of  this  task  is  a compendium  of 
nominal  operational  performance,  characteristic  performance  curves, 
expectations  of  behavior,  etc.  This  output  will  be  utilized  m the  pre- 
paration of  training  material  and  reference  handbook 

XXX-05-02-03-01  IUS  TRAINING  REQUIREMENTS,  EVALUATION  CRITERIA  AND 
SIMULATION  SCHEDULE 

This  task  accepts  as  inputs  the  IUS  console  position  guidelines,  operator 
certification  criteria,  procedures  and  mission  rules  and  from  that 
information  creates  a requirement  of  training  criteria  against  which 
successful  training  is  judged,  a definition  of  kind  and  content  of 
simulations  and  a schedule  for  classroom  and  simulation  training  for  a 
particular  mission  This  task  is  a recurring  task. 

XXX-10-01 -04-01  PREPARE  IUS  SYSTEM  HANDBOOK 

This  task  includes  all  efforts  required  to  generate  simplified  schematic 
diagrams,  simplified  interface  connections,  a summary  oT  component 
characteristics,  prediction  of  mission  events  and  performance  curves,  and 
inherent  IUS  constraints  and  limitations 

XXX-1 0-01 -04-02  PUBLISH  AND  UPDATE  IUS  SYSTEM  HANDBOOK 

The  basic  publication  of  an  IUS  system  handbook  will  incorporate  the 
information  prepared  for  that  purpose  under  one  cover.  The  updating  of  a 
system  handbook  will  be  on  a by-mission,  and  as  required,  basis,  and 
thus  is  an  iterative  task.  Major  updates  and  changes  to  the  IUS  baseline 
design  must  be  incorporated  into  the  systems  handbook  prior  to  the 
utilization  of  that  vehicle  for  a mission. 
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XXX-05-02-03-02  DEVELOP  IUS  TRAINING  MATERIAL 

This  task  includes  the  development  and  preparation  of  all  materials  required 
for  classroom  training  of  flight  controllers  and  flight  support  personnel 
This  includes  text  books,  handouts,  view  graphs,  reference  material,  etc. 

XXX-05-02-03-04  CLASSROOM  TRAINING 

This  task  includes  the  instructor's  time,  student's  time,  and  the  facilities 
required  for  conducting  classroom  training  in  the  characteristics  of  an  IUS 
vehicle,  the  mission,  and  support  networks.  Training  will  be  conducted  by 
flight  control  and  flight  support  personnel  m addition  to  their  normal 
operational  tasks. 

XXX-1 0-01 -05-03  IUS  NETWORK  DATA  HANDLING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  produce  a document  levying 
specific  data  handling,  processing,  and  special  processing  requirements  on 
the  supporting  network.  This  includes  both  updata  and  downdata  processing. 

XXX-1 0-01 -05-05  IUS  NETWORK  DATA  VALIDATION  PROCEDURES 

This  task  includes  all  efforts  required  to  establish  proof-of-performance 
criteria  for  the  acceptance  test  of  IUS  peculiar  ground  software. 

XXX-10-03-02  IUS  NETWORK  VALIDATION  TESTS 

This  task  includes  all  efforts  required  to  conduct  tests  of  the  network 
handling  of  IUS-peculiar  software,  including  the  providing  of  vehicle 
simulation  tapes  to  remote  sites  of  the  ground  data  acquisition  network, 
providing  the  procedures  to  remote  operators,  and  providing  personnel  to 
conduct  these  tests. 

XXX-1 5-02-03-02  PROGRAM  IUS  DOWN  DATA,  UP  DATA  AND  SIMULATION  SYSTEM 

This  task  includes  all  efforts  required  to  design  an  overall  software 
system  based  on  execution  rates,  mput/output  requirements,  and  response 
restrictions,  design  and  develop  IUS  specific  program  modules,  generating 
a detailed  software  design  document;  participation  in  design  reviews,  perform 
software  integration  testing,  participate  in  change  reviews  and  update 
software,  provide  configuration  control  and  perform  program  generation, 
delivery  and  validation. 

XXX-15-01-02-02  PROGRAM  IUS  FLIGHT  SOFTWARE 

This  task  includes  all  efforts  required  to  develop  pre-flight  and  flight 
software  to  satisfy  baseline  requirements.  Included  are  performance  of 
overall  software  system  design  based  on  execution  rates,  input/output 
requirements,  and  response  time  restrictions;  design  and  develop  executive 
and  application  program  modules;  generate  detailed  software  design 
documentaton , participate  in  design  reviews;  perform  systematic  integration 
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Table  10  1 1-2  I US  Operational  Element  Dictionary  (Continued) 


system  and  is  iterated  for  each  mission.  The  output  of  this  task  includes 
alternative  mission  definitions,  abort  profiles,  and  degraded  mission  plans 
This  task  is  conducted  roughly  in  parallel  with  the  development  of  IUS 
procedures  and  mission  rules  in  order  that  cross-feed  between  the  abort 
planning  and  contingency  operational  planning  may  take  place. 

XXX-01 -02-01 -08  IUS  INTERAGENCY  COORDINATION 

This  task  includes  all  efforts  required  to  establish  mutual  agreements 
with  DoD  and  NASA  centers  supporting  IUS  mission  operations.  This  includes 
the  coordination  of  program  support  requirement  and  ground  support  planning 

XXX-15-01 -02-03  IUS  FLIGHT  PROGRAM  VERIFICATION 

The  objective  of  program  verification  is  to  insure,  thru  systematic  testing 
by  a independent  functional  area,  that  the  flight  software  satisfies  all 
requirements  levied  on  it  by  the  equation  defining  document.  To  accomplish 
this  objective,  the  following  activities  are  performed  analysis  of  software 
requirements,  generation  of  a detailed  testing  plan,  performance  of  systematic 
tests,  analysis  of  software  listings,  comparison  of  flight  software  derived 
results  with  independently  generated  results,  analysis  of  hardware/software 
compability,  reverifi cation  of  all  changes  made  to  the  software  and  generation 
of  documented  test  results. 

XXX-01 -02-01 -07  PREPARE  IUS  INTERAGENCY  DOCUMENTATION 

This  task  includes  all  efforts  required  to  prepare  interagency  and  mter- 
center  coordination  documents.  A ground  support  plan  and  documents  which 
levy  requirements  on  other  government  agencies  or  other  NASA  centers.  The 
output  of  this  task  is  required  for  the  interagency  coordination  task. 

XXX— 1 5-02—05-01  PROGRAM  IUS  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  modify  the  baseline  IUS  simulator 
to  incorporate  mission  specific  profiles  and  contingency  cases.  This  task 
accepts  as  inputs  the  output  from  the  IUS  mission  planning  and  optimization 
task,  and  the  IUS  abort  planning  task,  as  well  as  outputs  from  IUS  basic 
simulation  design.  This  task  is  iterative  and  must  be  repeated  for  each 
flight.  This  task  is  in  a sense  a mission  specific  simulation  application 
module. 

XXX-15-01-03-01  IUS  MISSION  SPECIFIC  EQUATION  DEFINING  DOCUMENT  (EDD) 

This  task  includes  all  efforts  required  to  modify  the  definition  of  the 
baseline  IUS  flight  program  to  incorporate  mission  specific  peculiarities. 

This  task  is  iterative  and  must  be  repeated  prior  to  each  flight. 
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XXX-1 5-01 -03-02  IUS  MISSION  SPECIFIC  PROGRAMMING 

This  task  develops  the  "application  module"  which  incorporates  the  specific 
deviations  from  the  baseline  program  required  by  the  following  IUS  mission 
This  task  is  iterative  and  must  be  repeated  prior  to  each  flight 

XXX-15-01 -03-03  IUS  MISSION  PROGRAM  VERIFICATION 


This  task  includes  efforts  necessary  to  analyze  flight  program  implementation 
of  the  equation  defining  document  for  this  "application  module  “ The  task 
includes  generation  of  a detailed  testing  plan  to  insure  that  all  require- 
ments are  satisfied,  the  performance  of  systematic  tests,  and  generation  of 
a test  results  document 

XXX-05-02-03-05  IUS  MISSION  SIMULATION  TRAINING 

This  task  includes  the  simulation  of  the  specific  IUS  mission  for  nominal 
and  contingency  performance  cases  wherein  the  flight  support  personnel 
conduct  the  simulation  and  the  flight  control  personnel  are  judged  on  their 
ability  to  respond  to  contingency  situations  and  to  recognize  nominal  vehicle 
performance  This  task  is  iterative  and  must  be  repeated  prior  to  each 
flight. 

XXX-1 0-04  CONDUCT  IUS  MISSION  OPERATIONS 

This  task  includes  all  efforts  necessary  to  provide  control  and  support  to 
the  IUS  vehicle  in  prelaunch,  orbital  operations  and  placement  mission 
phases  This  task  requires  the  total  attention  of  the  flight  control  team, 
the  flight  support  team,  and  other  personnel.  This  task  is  the  culmination 
of  all  prior  efforts 

XXX-02-04-05-01  IUS  POST  MISSION  REPORTS 

This  task  includes  all  efforts  required  to  generate  two  post  mission  reports. 
An  evaluation  and  critique  report  is  prepared  by  the  flight  controllers  which 
define  the  performance  of  the  vehicle  as  viewed  from  the  position  of  a real 
time  console  operator.  The  third  report  is  the  maintenance  and  operations 
interface  report  which  evaluates  the  performance  of  the  data  gathering  and 
tracking  network  during  the  mission. 

XXX-02-04-01-03  DEFINE  IUS  OPERATOR  CERTIFICATION  CRITERIA 

This  task  includes  all  efforts  required  to  analyze  the  functions  of  the 
consoles  and  to  establish  appraisal  criteria  by  which  the  operator's 
performance  may  be  evaluated.  As  with  all  real  time  operations,  console 
operators  must  demonstrate  the  ability  to  perform  well  under  stress.  This 
task  analyses  the  stress  situations  which  the  operator  will  face  and 
establishes  the  criteria  by  which  the  operator's  performance  and  technical 
adequacy  are  to  be  judged 
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10  1 2 Space  Tug  Work  Breakdown  Structure 

Table  10  1 2-1  presents  the  Space  Tug  work  breakdown  structure  The  "320" 
designation  is  the  index  for  the  Space  Tug  program 

Portions  of  the  Space  Tug  WBS  dictionary  are  presented  in  Table  10  1 2-2 
The  complete  WBS  hierarchy  is  not  shown,  since  comparisons  with  the  similar 
elements  of  the  IUS  WBS  must  be  made  at  the  lowest  level  of  detail,  l e , 
where  a "product”  is  developed 
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Table  10.1 2-1  Space  Tug  WBS  Identification  Number  Sequence 


IDENTIFICATION  NUMBER 

ELEMENT  LEVEL 

320 

SPACE  TUG  PROJECT 

3 

320-01 

Project  Management 

4 

320-01-01 

Cost/Performance  Management 

5 

320-01-01-01 

Cost  Control  System 

5 

320-01-01-02 

Schedule  Control  System 

6 

320-01-02 

Project  Direction 

5 

320-01-02-01 

Development  Management 

6 

320-01-02-01-01 

Contract  Software  Development 

7 

320-01-02-01-02 

Plan  Facility  Utilization 

7 

320-01-02-01-03 

Computer  Utilization  Plan 

7 

320-01-02-01-04 

Maintenance  Schedule 

7 

320-01-02-01-05 

Hire  Control  and  Support  Staff 

7 

320-01-02-01-06 

Obtain  Space  Tug  System  Characteristics 

7 

320-01-02-01-07 

Prepare  Tug  Interagency  Documents 

7 

320-01-02-01-08 

Tug  Interagency  Coordination 

7 

320-01-02-02 

Quality  Management 

6 

320-01-02-03 

Logistics  Management 

6 

320-01-02-04 

Engineering  Administration 

6 

320-01-03 

Information  Management 

6 

320-02 

Systems  Engineering 

4 

320-02-01 

Tug  Systems  Engineering 

5 

320-02-01-01 

Master  Launch  Schedule  Analysis 

6 

320-02-01-02 

Tug  Mission  Characterization 

6 

320-02-01-03 

Determine  Tug  Failure  Modes 

6 

320-02-02 

Shuttle  Interface 

5 

320-02-03 

Payload  Interface 

5 

320-02-04 

Sustaining  Engineering 

5 

320-02-04-01 

Flight  Control  Engineering 

6 

320-02-04-01-01 

Mission  Phase  Manning  Requirements 

7 

320-02-04-01-02 

Tug  Console  Position  Guidelines 

7 

320-02-04-01-03 

Define  Tug  Operator  Certification/Criteria 

7 

320-02-04-01-04 

Validation  Test  Requirements-Fundamental 

Tug  Ground  Programs 

7 

320-02-04-01-05 

Tug  Ground  Validation  Test  Requirements 

7 

320-02-04-02 

Flight  Support  Engineering 

6 

320-02-04-02-01 

Select  Operational  Data  System 

7 

320-02-04-03 

Mission  Engineering 

b 

•320-02-04-03-01 

Tug  Mission  Planning  and  Optimization 

7 

320-02-04-03-02 

Tug  Abort  Planning 

7 

320-02-04-05 

Mission  Evaluation  Engineering 

6 

320-02-04-05-01 

Tug  Post  Mission  Reports 

7 

320-03 

Tug  Vehicle  Main  Stage 

4 

320-05 

Logistics 

4 

320-05-01 

Transportation  and  Handling 

5 

320-05-02 

Training 

5 
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Table  10  1 2-1.  Space  Tug  IVBS  Identification  Number  Sequence  (Continued) 


IDENTIFICATION  NUMBER 

ELEMENT 

LEVEL 

320-05-02-01 

Simulators  and  Equipment 

6 

320-05-02-02 

Ground  Crew  Training 

6 

320-05-02-03 

Flight  Operations  Crew  Training 

6 

320-05-02-03-01 

Tug  Training  Requirement/Criteria/Simsked 

7 

320-05-02-03-02 

Develop  Tug  Training  Material 

7 

320-05-02-03-03 

Design  Tug  Mission  Simulation 

7 

320-05-02-03-04 

Tug  Classroom  Training 

7 

320-05-02-03-05 

Tug  Mission  Simulation  Training 

7 

320-06 

Facilities 

4 

320-06-01 

Manufacturing 

5 

320-06-02 

Test 

5 

320-06-03 

Maintenance  and  Refurbishment 

5 

320-06-04 

ETR  Launch 

5 

320-06-05 

WTR  Launch 

5 

320-06-06 

Flight  Operations  Facility 

5 

320-06-06-01 

Size  Facility/Design  Physical  Plant 

6 

320-06-06-02 

Construct  Physical  Plant 

6 

320-07 

Ground  Support  Equipment  (GSE) 

4 

320-07-01 

Manufacturing  and  Test  GSE 

5 

320-07-02 

Eastern  Test  Range  GSE 

5 

320-07-03 

Western  Test  Range  GSE 

5 

320-07-04 

Flight  Operations  GSE 

5 

320-07-04-01 

Install  Operational  Data  System 

6 

320-07-04-02 

Install  Operational  Consoles/Hardware 

6 

320-08 

Vehicle  Test 

4 

320-09 

Launch  Operations 

4 

320-10 

Flight  Operations 

4 

320-10-01 

Mission  Planning  and  Documentation 

5 

320-10-01-01 

Develop  Tug  Procedures  and  Rules 

6 

320-10-01-02 

Tug  Mission  Failure  Effects 

6 

320-10-01-03 

Analyze  Tug  Component  Characteristics 

6 

320-10-01-04 

Flight  Control  Systems  Handbook 

6 

320-10-01-04-01 

Prepare  Tug  Systems  Handbook 

7 

320-10-01-04-02 

Publish/Update  Tug  Systems  Handbook 

7 

320-10-01-05 

Tug  Network  Interface  Documentation 

6 

320-10-01-05-03 

Tug  Network  Data  Handling  Requirements 

7 

320-10-01-05-04 

Tug  Network  Data  Validation  Procedures 

7 

320-10-02 

Operational  Preparations 

5 

320-10-02-01 

Design  Network  Interface  System 

6 

320-10-02-02 

Console  Organization 

6 

320-10-02-03 

Tug  Display  Format  Design 

6 

320-10-03 

Mission  Readiness  Testing 

5 

320-10-03-02 

Tug  Network  Validation  Tests 

6 

320-10-04 

Conduct  Tug  Mission  Operations 

5 

320-11 

Refurbishment  and  Integration 

4 
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IDENTIFICATION  NUMBER 

ELEMENT 

LEVEL 

320-15 

Software 

4 

320-15-01 

Flight  Software 

5 

320-15-01-01 

Plan  Flight  Software  Development 

6 

320-15-01-02 

Baseline  Flight  Program  Development 

6 

320-15-01-02-01 

EDD  - Tug  Flight  Program 

7 

320-15-01-02-02 

Program  Tug  Flight  Software 

7 

320-15-01-02-03 

Tug  Flight  Program  Verification 

7 

320-15-01-03 

Mission  Specific  Program  Modification 

6 

320-15-01-03-01 

Tug  Mission  Specific  EDD 

7 

320-15-01-03-02 

Tug  Mission  Specific  Program 

7 

320-15-01-03-03 

Tug  Mission  Program  Verification 

7 

320-15-02 

Ground  Software 

5 

320-15-02-01 

Plan  Ground  Software  Development 

6 

320-15-02-02 

Equation  Definition 

6 

320-15-02-02-01 

EDD  - Executi  ve/Planmng 

7 

320-15-02-02-02 

EDD  - Tug  Dndata/Updata/Docking/Sim 

7 

320-15-02-03 

Programming 

6 

320-15-02-03-01 

Program  Ground  EX/Planmng  SW 

7 

320-15-02-03-02 

Program  Tug  Dndata/Updata/Docking/Sim 

7 

320-15-02-04 

Program  Verification 

6 

320-15-02-04-01 

Verify  Executi  ve/Planmng  SW 

7 

320-15-02-04-02 

Verify  Tug  Dndata/Updata/Docking/Sim 

7 

320-15-02-05 

Mission  Specific  Simulation 

6 

320-15-02-05-01 

Program  Tug  Mission  Simulation 

7 

320-15-03 

Computer  Selection  Support 

5 

320-15-03-01 

Estimate  Ground  Software  Size 

6 

320-16 

Orbiter  Interface 

4 
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Table  10  1 2-2  Space  Tug  Operational  Element  Dictionary 


320-02-01-01  MASTER  LAUNCH  SCHEDULE  ANALYSIS 


The  master  Launch  Schedule  will  be  analyzed  to  determine  the  type,  spacing, 
and  frequency  of  Space  Tug  flights.  This  task  will  establish  the  range  of 
mission  types,  trajectories,  payload  accommodations  and  control  facility 
utilization  requirements  across  the  Space  Tug  operational  period.  This 
task  is  a predecessor  to  the  establishment  of  Tug  mission  characteristics 
and  control  facility  utilization  planning. 

320-01-02-01-01  CONTRACT  SOFTWARE  DEVELOPMENT 


This  task  includes  all  effort  necessary  to  prepare  a Statement  of  Work, 
evaluate  proposals  and  provide  financial  contracting  and  procurement 
support  in  order  to  place  an  outside  contractor  under  contract  for 
development  of  ground  and  flight  software. 

320-01-02-01-02  PLAN  FACILITY  UTILIZATION 

This  task  includes  all  efforts  involved  in  establishing  a coherent  plan 
for  the  utilization  of  a Mission  Control  facility.  This  will  include 
such  things  as  scheduling  of  activities,  program  sharing,  office,  canteen, 
technical  support  area  and  other  generic  requirements  which  impact  facility 
design. 

320-15-01-01  PLAN  FLIGHT  SOFTWARE  DEVELOPMENT 


This  task  includes  all  efforts  required  to  establish  a schedule  for 
development  of  the  flight  software,  establish  design  concept  validation 
procedures,  establish  the  necessity  for,  and  required  characteristics  of, 
hybrid  and  interpretive  simulators,  and  establishing  controls  and  feedback 
to  insure  customer  requirements  on  the  Space  Tug  flight  software  are 
ful filled. 

320-15-02-01  PLAN  GROUND  SOFTWARE  DEVELOPMENT 


This  task  includes  all  efforts  necessary  to  establish  a plan  for  the 
development  of  Space  Tug  ground  software.  Included  will  be  the 
advisability  of  transforming  software  modules  from  existing  ground  control 
systems,  establishment  of  the  basic  data  processing  techniques,  planning 
the  use  of  existing  ground  system  simulators  and  establishing  ground 
program  organizations  and  source  strings 

320-02-04-01-01  MISSION  PHASE  MANNING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  types  and  quantity 
of  personnel  required  to  support  Space  Tug  flight  control  and  flight  support 
activities.  It  will  include  an  analysis  of  the  mission  density,  the  overlap 
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Table  10  1 2-2  Space  Tug  Operational  Element  Dictionary  (Continued) 


between  adjacent  modules  in  the  mission  structure  and  will  establish  the 
control  and  support  necessary  to  accomplish  the  Space  Tug  missions  with 
a minimum  loss  of  productive  man  hours 

320-01-02-01-03  COMPUTER  UTILIZATION  PLAN 

This  task  includes  all  efforts  required  to  develop  and  enforce  a plan  to 
maximize  the  utilization  of  the  computational  facility  incorporated  in 
the  Tug  ground  control  complex  This  will  include  a pre-emption  hierarchy, 
mission  planning  schedule,  mission  operation  schedule,  batch  processing 
schedule,  etc. 

320-01-02-01-04  MAINTENANCE  SCHEDULE 

This  task  establishes  the  housekeeping  and  periodic  maintenance  require- 
ments of  the  control  center  and  associated  equipments.  This  task  includes 
the  contracting  for,  and  administration  of,  specific  external  maintenance 
of  the  data  system,  plant  environmental  control  mechanisms,  and  janitorial 
services.  Periodic  and  specific  maintenance  of  the  flight  control  and 
flight  support  console  items  will  be  conducted  by  the  permanent  party 
flight  support  staff. 

320-01-02-01-05  HIRE  CONTROL  AND  SUPPORT  STAFF 

This  task  includes  all  efforts  required  to  procure  competent  personnel  to 
perform  flight  control  tasks  in  the  technical  disciplines  of  propulsion, 
avionics,  networks,  communication,  guidance,  dynamics,  data  selection, 
television,  and  docking.  It  also  includes  the  efforts  required  to  hire 
flight  support  personnel  in  the  technical  disciplines  of  facility 
supervisor,  data  systems,  maintenance  operations  and  software  support 

320-10-02-03  CONSOLE  ORGANIZATION 

This  task  includes  all  efforts  necessary  to  establish  the  requirements 
for  location  of  console  display  and  control  devices  to  the  satisfaction 
of  the  console  operating  personnel 

320-10-02-01  DESIGN  NETWORK  INTERFACE 

This  task  includes  the  engineering  effort  necessary  to  establish  the 
interface  with  the  data  acquisition  network.  It  specifically  includes 
telemetry  decommutation  and  special  processing,  command  processing  and 
television  processing  requirements.  The  output  of  this  task  will  be 
the  operational  requirements  for  a network  interface  systems  design 
which  will  include  suggested  hardware  items 
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320-15-03-01  ESTIMATE  GROUND  SOFTWARE  SIZE 

This  task  analyzes  the  equation  defining  document  for  ground  software  and 
establishes  a lower  boundary  upon  the  data  system  memory  size  and  central 
processor  unit  speed  requirements.  For  maximum  cost  effectiveness  this  task 
must  be  completed  prior  to  the  selection  of  an  operational  data  system. 

320-02-04-02-01  SELECT  OPERATIONAL  DATA  SYSTEM 

Tins  task  includes  all  efforts  required  to  establish  the  integrated 
requirements  of  an  operational  data  system  and  takes  into  account  the 
ground  software  size  estimate,  the  computer  utilization  plan,  and 
growth  factors.  This  task  also  includes  all  procurement  and  purchase 
operations  necessary  in  the  buy  of  an  operational  data  system,  and  the 
engineering  of  the  data  system  configuration 

320-07-04-01  INSTALL  OPERATIONAL  DATA  SYSTEM 

This  task  includes  all  efforts  by  the  data  system  contractor  to  install 
diagnose  and  checkout  the  completed  system  installation.  At  the  end  of 
this  task,  the  data  processing  system  will  be  on-line  and  operational 
ready  to  support  future  data  processing  activities. 

320-06-06-01  SIZE  FACILITY/DESIGN  PHYSICAL  PLANT 

Prior  to  beginning  this  task,  the  operational  data  system  will  have  been 
selected,  the  network  interface  design  will  have  been  completed  and 
equipment  selected,  and  the  console  equipment  designed  and  ordered.  This 
task  includes  the  architectural  design  of  the  facility. 

320-06-06-02  CONSTRUCT  PHYSICAL  PLANT 

This  task  includes  the  efforts  involved  by  a building  contractor  to 
perform  site  preparation,  construction  of  a physical  plant,  environmental 
control  and  electrical  installations  on  the  structure. 

320-07-04-02  INSTALL  OPERATIONAL  CONSOLES 

This  task  includes  the  installation  of  the  console  hardware  and  associated 
interface  equipments  This  task  presumes  that  the  consoles  will  be 
delivered  to  the  finished  physical  plant  by  a vendor  and  then  will  be 
installed  by  flight  support  technicians. 

320-15-02-02-01  EQUATION  DEFINING  DOCUMENT  - EXECUTIVE/PLANNING  SOFTWARE 


This  task  includes  those  efforts  in  the  definition  and  analysis  leading  to 
the  development  of  the  equations  and  algorithms  to  be  utilized  in  the 
fundamental  Space  Tug  ground  programs 
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320-02-04-01-04  VALIDATION  TEST  REQUIREMENTS  - FUNDAMENTAL  TUG  GROUND 
REQUIREMENTS 

This  task  includes  the  establishment  of  proof-of-performance  parameters 
for  the  software  which  is  fundamental  to  the  Space  Tug  operations.  This 
task  establishes  the  vital  criteria  against  which  the  program  performance 
is  to  be  evaluated,  and  should  be  conducted  independently  of  the  Equation 
Definition  generation. 

320-15-02-03-01  PROGRAM  GROUND  PLANNING  AND  EXECUTIVE  ROUTINES 

This  task  depends  on  the  generation  of  an  adequate  Equation  Defining 
Document  at  a prior  time,  and  includes  the  programming  of  all  fundamental 
routines. 

320-15-02-04-01  VERIFY  EXECUTIVE  AND  PLANNING  SOFTWARE 

This  task  verifies  that  the  intent  of  the  Equation  Defining  Document  has 
been  implemented  in  the  developed  programs  by  testing  the  coded  program 
under  critical  operational  situations  and  includes  the  development  of  any 
special  tools  or  simulators  necessary  in  the  accomplishment  of  this  task 

320-01-02-01-06  OBTAIN  SPACE  TUG  SYSTEM  CHARACTERISTICS 

This  task  includes  all  efforts  necessary  to  acquire  catalog,  define  and 
analyze  the  operational  characteristics  of  the  Space  Tug  system.  The 
output  of  this  task  is  utilized  in  the  development  of  flight  controller 
display  designs,  network  telemetry  and  updata  interface  system  design 
and  as  primary  input  into  the  determination  of  operational  failure  modes 

320-02-01-02  TUG  MISSION  CHARACTERISTICS 

This  task  accepts  the  output  on  the  master  launch  schedule  analysis  task 
and  operates  on  that  output  to  determine  the  specific  characteristics  of 
all  defined  Space  Tug  missions.  The  output  of  this  task  is  utilized  in 
the  determination  of  mission  phase  manning  requirements,  definition  of 
Space  Tug  operator  certification  (and  criteria  for  certification),  a 
computer  utilization  plan  for  the  Space  Tug  portion  of  the  Shuttle  era 
and  the  associated  maintenance  schedule 

320-15-01-02-01  EQUATION  DEFINING  DOCUMENT  - SPACE  TUG  FLIGHT  PROGRAM 

This  task  includes  basic  conceptual  work  on  the  requirements  for  flight 
software,  customer  support  and  flight  software  definition,  definitions 
of  equations  pertaining  to  vehicle  dynamics,  a design  of  algonth  techniques 
and  the  associated  simulation  equipments,  the  generation  of  a program 
requirements  document  known  as  the  Equation  Defining  Document  (EDD), 
control  of  requirements,  performance  of  software  implementation  studies, 
analysis  of  sample  calculations,  definition  of  flight  control  functional 
interfaces,  definition  of  hardware  interfaces,  and  miscellaneous 
preliminary  analysis. 
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320-15-02-02-02  TUG  DOWN  DATA/UP  DATA  AND  DOCKING  GROUND  SOFTWARE 

This  task  includes  all  efforts  required  to  create  an  Equation  Defining 
Document  (EDD)  for  those  ground  software  modules  which  are  specifically 
oriented  to  the  Space  Tug.  The  output  of  this  task  is  an  Equation 
Defining  Document  against  which  the  ground  Tug-peculiar  software  will  be 
programmed. 

320-02-04-01-05  TUG  GROUND  VALIDATION  TEST  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  criteria  for 
acceptance  or  rejection  of  Space  Tug  peculiar  ground  software.  This 
task  is  performed  independently  of  the  programming  effort  and  is 
specifically  to  establish  proof-of-performance  standards  against  which 
the  program  will  be  judged. 

320-02-01-03  DETERMINE  TUG  FAILURE  MODES 

After  the  Space  Tug  system  characteristics  have  been  obtained,  categorized 
and  defined,  the  systems  will  be  analyzed  for  high  probability  failure  modes. 
The  output  of  this  task  will  be  a list  of  potential  failures,  which  can 
impact  the  operational  performance  of  the  vehicle.  Failures  of  a cosmetic 
nature  will  not  be  considered.  The  output  of  this  task  is  a list  of  high 
probability  failure  modes  which  will  then  be  analyzed  for  the  overall 
mission  effect  of  that  failure. 

320-10-02-03  TUG  DISPLAY  FORMAT  DESIGN 

This  task  includes  all  efforts  required  to  establish  the  organization, 
display  format  and  engineering  units  for  flight  control  and  flight  support 
personnel  digital  TV  presentation.  This  task  also  includes  all  efforts 
directed  toward  the  definition  of  the  special  processing  requirements, 
remote  site  and  control  center  logical  operations,  limit  sensing,  event 
light  triggering,  etc. 

320-10-01-02  TUG  MISSION  FAILURE  EFFECTS  ANALYSIS 

Once  the  Space  Tug  failure  modes  have  been  identified  and  categorized,  the 
occurance  of  these  failures  at  various  points  in  the  flight  must  be  evaluated 
for  overall  mission  effect.  The  output  of  this  task  will  be  a series  of 
scenarios  against  which  pre-thought  decisions  may  be  constructed 

320-05-02-03-03  DESIGN  TUG  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  integrate  the  results  of  the 
Space  Tug  procedures  and  rules,  the  optimum  and  abort  mission  timelines, 
and  operator  training  criteria  into  a Tug  mission  specific  simulation 
design.  This  task  will  be  accomplished  both  in  the  DDT&E  phase  and  in  the 
recurring  phase  of  the  Space  Tug  program.  A specific  simulation  design  will 
be  formulated  for  each  mission.  The  flight  controller  and  flight  support 
personnel  will  be  trained  against  the  mission  specific  simulation  in 


10-23 


Table  10  1 2-2  Space  Tug  Operational  Element  Dictionary  (Continued) 


preparation  for  their  operational  roles.  The  output  of  this  task  is  a set 
of  malfunctions,  predicted  responses  and  operator  performance  evaluation 
criteria 

320-10-01-03  ANALYZE  TUG  COMPONENT  CHARACTERISTICS 

This  task  includes  all  efforts  required  to  assemble  basic  operational 
information  describing  the  characteristics  of  the  operationally  significant 
components  of  the  Tug  vehicle.  The  output  of  this  task  is  a compendium  of 
nominal  operational  performance,  characteristic  performance  curves, 
expectations  of  behavior,  etc  This  output  will  be  utilized  in  the  pre- 
paration of  training  material  and  reference  handbook. 

320-05-02-03-01  TUG  TRAINING  REQUIREMENTS,  EVALUATION  CRITERIA  AND 
SIMULATION  SCHEDULE 

This  task  accepts  as  inputs  the  Space  Tug  console  position  guidelines, 
operator  certification  criteria,  procedures  and  mission  rules  and  from  that 
information  creates  a requirement  for  training  criteria  against  which 
successful  training  is  judged,  a definition  of  kind  and  content  of 
simulations  and  a schedule  for  classroom  and  simulation  training  for  a 
particular  mission.  This  task  is  a recurring  task. 

320-10-01-04-01  PREPARE  TUG  SYSTEM  HANDBOOK 

This  task  includes  all  efforts  required  to  generate  simplified  schematic 
diagrams,  simplified  interface  connections,  a summary  of  component 
characteristics,  prediction  of  mission  events  and  performance  curves,  and 
inherent  Space  Tug  constraints  and  limitations. 

320-10-01-04-02  PUBLISH  AND  UPDATE  SPACE  TUG  SYSTEM  HANDBOOK 

The  basic  publication  of  a Space  Tug  system  handbook  will  incorporate  the 
information  prepared  for  that  purpose  under  one  cover.  The  updating  of  a 
system  handbook  will  be  on  a by-mission,  and  as  required,  basis,  and  thus, 
is  an  iterative  task  Major  updates  and  changes  to  the  Space  Tug  baseline 
design  must  be  incorporated  into  the  systems  handbook  prior  to  the 
utilization  of  that  vehicle  for  a mission. 

320-05-02-03-02  DEVELOP  SPACE  TUG  TRAINING  MATERIAL 

This  task  includes  the  development  and  preparation  of  all  materials  required 
for  classroom  training  of  flight  controllers  and  flight  support  personnel. 
This  includes  text  books,  handouts,  view  graphs,  reference  material,  etc. 

320-05-02-03-04  SPACE  TUG  CLASSROOM  TRAINING 

This  task  includes  the  instructor's  time,  student's  time,  and  the  facilities 
required  for  conducting  classroom  training  in  the  characteristics  of  a 
Space  Tug  vehicle,  the  mission  and  support  networks.  Training  will  be 
conducted  by  flight  control  and  flight  support  personnel  in  addition  to 
their  normal  operational  tasks. 


10-24 


Table  10  1 2-2  Space  Tug  Operational  Element  Dictionary  (Continued) 


320-10-01-05-03  SPACE  TUG  NETWORK  DATA  HANDLING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  produce  a document  levying 
specific  data  handling*  processing,  and  special  processing  requirements 
on  the  supporting  network.  This  includes  both  updata  and  downdata 
processing. 

320-10-01-05-05  TUG  NETWORK  DATA  VALIDATION  PROCEDURES 

This  task  includes  all  efforts  required  to  establish  proof-of-performance 
criteria  for  the  acceptance  test  of  Tug-peculiar  ground  software. 

320-10-03-02  SPACE  TUG  NETWORK  VALIDATION  TESTS 

This  task  includes  all  efforts  required  to  conduct  tests  of  the  network 
handling  of  Space  Tug  peculiar  software,  including  the  providing  of  vehicle 
simulation  tapes  to  remote  sites  of  the  ground  data  acqusition  network, 
providing  the  procedures  to  remote  operators,  and  providing  personnel  to 
conduct  these  tests. 

320-15-02-03-02  PROGRAM  SPACE  TUG  DOWN  DATA,  UP  DATA  AND  SIMULATION  SYSTEM 

This  task  includes  all  efforts  required  to  design  an  overall  software  system 
based  on  execution  rates,  input/output  requirements,  and  response  restrictions; 
design  and  develop  Tug  specific  program  modules,  generating  a detailed 
software  design  document,  participation  in  design  reviews,  perform  software 
integration  testing,  participate  in  change  reviews  and  update  software, 
provide  configuration  control  and  perform  program  generation,  delivery  and 
validation. 

320-15-01-02-02  PROGRAM  TUG  FLIGHT  SOFTWARE 

This  task  includes  all  efforts  required  to  develop  pre-flight  and  flight 
software  to  satisfy  baseline  requirements.  Included  are  performance  of 
overall  software  system  design  based  on  execution  rates,  input/output 
requirements,  and  response  time  restrictions,  design  and  develop  executive 
and  application  program  modules,  generate  detailed  software  design 
documentation;  participate  in  design  reviews,  perform  systematic 
integration  testing  of  software,  update  software  as  a result  of  change 
activity,  participate  in  configuration  control,  perform  program  delivery 
generation  and  validation,  and  provide  customer  support  as  required 

320-15-02-04-02  VERIFY  TUG  DOWN  DATA,  UPDATA  AND  SIMULATION  PROGRAMMING 

This  task  includes  all  activities  involved  to  insure,  thru  systematic  testing 
by  a independent  functional  area,  that  the  Tug  peculiar  ground  software 
satisfies  all  requirements  levied  upon  it  by  the  equation  definition  document. 
This  includes  analysis  of  software  requirements  to  insure  accuracy,  adequacy, 
and  completeness,  generation  of  a detailed  testing  plan,  performance  of 
systematic  tests  utilizing  interpretive  simulators,  analysis  of  software 
listings,  analysis  of  hardware/software  compatibility  and  validation  of  all 
changes  made  to  the  basic  software  package 
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320-02-04-01-02  TUG  CONSOLE  POSITION  GUIDELINES 

This  task  includes  all  activities  required  to  establish  generic  position 
responsibilities  as  a function  of  console  and  technical  discipline  This 
activity  is  based  upon  the  mission  phase  manning  requirements  and  the 
output  is  utilized  as  one  input  to  the  mission  simulation  design  and  to  the 
Space  Tug  requirements  criteria,  simulation  and  scheduled  tasks.  The  output 
of  this  task  establishes  the  organizational  reporting  tree  authority  invested 
in  the  greater  positions  and  both  technical  and  hierarchial  relationships. 

320-02-04-03-01  TUG  MISSION  PLANNING  AND  OPTIMIZATION 

This  task  is  iterative  and  includes  the  basic  design  of  trajectory,  timing 
of  burns,  and  error  propagation  analysis  leading  to  the  design  of  the 
mission  flight  plan  This  task  will  be  performed  on  the  operational  computer 
utilizing  software  specially  developed  for  the  purpose.  The  output  of  this 
task,  and  the  output  from  the  associated  Space  Tug  abort  planning  task  are 
utilized  to  establish  the  mission  specific  deviations  from  the  Space  Tug 
flight  program  baseline,  and  to  provide  an  input  to  the  mission  specific 
simulation  development. 

320-10-01-01  DEVELOP  TUG  PROCEDURES  AND  RULES 

The  specific  rules  and  procedures  utilized  during  the  mission  will  consists 
of  a fundamental  set  of  procedures  and  rules  which  are  applicable  across 
all  Tug  missions,  and  a mission  specific  set  of  rules  and  procedures.  The 
output  of  this  task  is  a document  containing  all  predefined  mission  decisions, 
a document  containing  basic  step-by-step  implementation  procedures,  a set 
of  predefined  contingency  procedures  and  a vehicle  command  listing. 

320-02-04-03-02  TUG  ABORT  PLANNING 

After  the  basic  mission  planning  and  optimization  has  been  completed,  certain 
off-nominal  malfunction,  abort  and  contingency  conditions  must  be  investigated 
and  contingency  operational  procedures  developed  to  handle  those  situations. 
This  task  utilizes  special  software  programmed  into  the  operational  computer 
system  and  is  iterated  for  each  mission.  The  output  of  this  task  includes 
alternative  mission  definitions,  abort  profiles,  and  degraded  mission  plans 
This  task  is  conducted  roughly  in  parallel  with  the  development  of  Tug 
procedures  and  mission  rules  in  order  that  cross  feed  between  the  abort 
planning  and  contingency  operational  planning  may  take  place. 

320-01-02-01-08  SPACE  TUG  INTERAGENCY  COORDINATION 

This  task  includes  all  efforts  required  to  establish  mutual  agreements  with 
DoD  and  NASA  centers  supporting  Space  Tug  mission  operations  This  includes 
the  coordination  of  program  support  requirement  and  ground  support  planning. 


10-26 


Table  10. 1 2-2  Space  Tug  Operational  Element  Dictionary  (Continued) 


320-15-01-02-03  SPACE  TUG  FLIGHT  PROGRAM  VERIFICATION 

The  objective  of  program  verification  is  to  insure,  thru  systematic  testing 
by  a independent  functional  area,  that  the  flight  software  satisfies  all 
requirements  levied  on  it  by  the  Equation  Defining  Document.  To  accomplish 
this  objective  the  following  activities  are  performed  analysis  of  software 
requirements,  generation  of  a detailed  testing  plan,  performance  of  systematic 
tests,  analysis  of  software  listings,  comparison  of  flight  software  derived 
results  with  independently  generated  results,  analysis  of  hardware/software 
compatibility,  reverifi cation  of  all  changes  made  to  the  software  and 
generation  of  documented  test  results. 

320-01-02-01-07  PREPARE  TUG  INTERAGENCY  DOCUMENTATION 

This  task  includes  all  efforts  required  to  prepare  interagency  and  mter- 
center  coordination  documents.  A ground  support  plan  and  documents  which 
levy  requirements  on  other  government  agencies  or  other  NASA  centers. 

The  output  of  this  task  is  required  for  the  interagency  coordination  task 

320-15-02-05-01  PROGRAM  TUG  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  modify  the  baseline  Tug  simulator 
to  incorporate  mission  specific  profiles  and  contingency  cases  This  task 
accepts  as  inputs  the  output  from  the  Space  Tug  mission  planning  and 
optimization  task,  and  the  Space  Tug  abort  planning  task,  as  well  as  outputs 
from  Space  Tug  basic  simulation  design.  This  task  is  iterative  and  must  be 
repeated  for  each  flight.  This  task  is  in  a sense  a mission  specific 
simulation  application  module. 

320-15-01-03-01  TUG  MISSION  SPECIFIC  EQUATION  DEFINING  DOCUMENT  (EDD) 

This  task  includes  all  efforts  required  to  modify  the  definition  of  the 
baseline  Space  Tug  flight  program  to  incorporate  mission  specific  peculanties. 
This  task  is  iterative  and  must  be  repeated  prior  to  each  flight 

320-15-01-03-02  TUG  MISSION  SPECIFIC  PROGRAMMING 

This  task  develops  the  "application  module"  which  incorporates  the  specific 
deviations  from  the  baseline  program  required  by  the  following  Space  Tug 
mission.  This  task  is  iterative  and  must  be  repeated  prior  to  each  flight. 

320-15-01-03-03  TUG  MISSION  PROGRAM  VERIFICATION 

This  task  includes  efforts  necessary  to  analyze  flight  program  implementation 
of  the  equation  defining  document  for  this  "application  module".  The  task 
includes  generation  of  a detailed  testing  plan  to  insure  that  all  require- 
ments are  satisfied,  the  performance  of  systematic  tests,  and  generation  of 
a test  results  document. 
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Table  10.1 2-2  Space  Tug  Operational  Element  Dictionary  (Continued) 


320-05-02-03-05  TUG  MISSION  SIMULATION  TRAINING 


This  task  includes  the  simulation  of  the  specific  Space  Tug  mission  for 
nominal  and  contingency  performance  cases  where  in  the  flight  support 
personnel  conduct  the  simulation  and  the  flight  control  personnel  are 
judged  on  their  ability  to  respond  to  contingency  situations  and  to 
recognize  nominal  vehicle  performance  This  task  is  iterative  and  must  be 
repeated  prior  to  each  flight 

320-10-04  CONDUCT  SPACE  TUG  MISSION  OPERATIONS 

This  task  includes  all  efforts  necessary  to  provide  control  and  support  to 
the  Space  Tug  vehicle  in  prelaunch,  orbital  operations,  placement,  retrieval 
and  landing  phases.  This  task  requires  the  total  attention  of  the  flight 
control  team,  the  flight  support  team,  and  other  personnel  This  task  is 
the  culmination  of  all  prior  efforts. 

320-02-04-05-01  SPACE  TUG  POST  MISSION  REPORTS 

This  task  includes  all  efforts  required  to  generate  three  post  mission 
reports.  An  evaluation  and  critique  report  prepared  by  the  flight 
controllers  which  define  the  performance  of  the  vehicle  as  viewed  from 
the  position  of  a real  time  console  operator.  A maintenance  interface 
report  prepared  by  the  flight  control  personnel  which  summarizes  the 
observations  made  in  real  time  which  imply  maintenance  requirements  against 
the  flight  stage.  This  report  is  forwarded  to  the  launch  center  for 
incorporation  in  the  Specific  Vehicle  Maintenance  Plan.  The  third  report 
is  the  maintenance  and  operations  interface  report  which  evaluates  the 
performance  of  the  data  gathering  and  tracking  network  during  the  mission 

320-02-04-01-03  DEFINE  TUG  OPERATOR  CERTIFICATION  CRITERIA 

This  task  includes  all  efforts  required  to  analyze  the  functions  of  the 
consoles  and  to  establish  appraisal  criteria  by  which  the  operator's  per- 
formance may  be  evaluated.  As  with  all  real  time  operations,  console 
operators  must  demonstrate  the  ability  to  perform  well  under  stress.  This 
task  analyses  the  stress  situations  which  the  operator  will  face  and 
establishes  the  criteria  by  which  the  operator's  performance  and  technical 
adequacy  are  to  be  judged. 
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10.2  COMPARISON  OF  SPACE  TUG  AND  IUS  OPERATIONAL  ELEMENTS 

The  work  breakdown  structures  developed  for  IUS  and  Space  Tug  programs 
are  compared  in  Table  10  2 0-1  The  columns  "C",  "TU\  "IU"  and  "M" 
designate  the  WBS  elements  to  be  "common"  (or  very  close),  "Tug  Unique", 
"IUS  Unique"  or  "Modifiable" 

Each  line  item  resulting  in  a "product"  from  both  work  breakdown  structures 
is  presented  and  an  assessment  made  as  to  which  category  that  line  item 
would  fit  in  an  integrated  program. 

Explanations  of  the  categorizations  are  supplied  in  the  "Comments"  field. 

Basically,  if  a WBS  line  item  is  dependent  upon  factors  outside  the  vehicle 
design  sphere  of  influence,  that  line  item  is  judged  to  be  common  to  both 
IUS  and  Space  Tug  programs.  On  the  other  hand,  if  the  WBS  line  item  is 
dependent  upon  vehicle  design,  it  is  judged  to  be  "IUS  Unique"  or  "Space 
Tug  Unique"  "Modifiable"  WBS  line  items  are  those  which  are  initiated 
on  the  IUS  program  and  phase  over  into  the  Space  Tug  program  with  some 
changes  incorporated.  Such  items  typically  involve  combinations  of  vehicle 
and  external  influences. 
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Table  10  2 0-1  Comparison  of  Space  Tug  and  /US  Operational  Elements 


WBS  320-  OR  XXX- 

TITLE 

c 

TU 

IU 

M 

COMMENTS 

02-01-01 

Master  Launch  Schedule  Analysis 

/ 

This  task  may  be  shared  by  enlarging 
the  scope  of  work  - no  unique  factors. 

01-02-01-01 

Contract  Software  Development 

/ 

Mission  timing  and  common  utilization 
of  data  processing  equipment  make 
combining  of  software  under  one 
contractor  attractively  cost-effective 

01-02-01-02 

Plan  Facility  Utilization 

/ 

A single  facility  for  both  IUS  and  Tug 
mission  control  makes  this  a common 
task 

15-01-01 

P^an  Flight  Software  Development 

/ 

Total  IUS/Tug  program  cost  can  be 
minimized  by  integrating  flight 
software  development  techniques, 
simulator,  etc 

15-02-01 

Plan  Ground  Software  Development 

/ 

Ground  software  will  be  driven  by 

1)  IUS  TM  and  CMD  configuration, 

2)  Tug  TM  and  CMD  configuration,  and 

3)  Ground  system  (network)  config- 
uration A unified  plan  will  save 
double  development  costs  for  3) 

02-04-01-01 

Mission  Phase  Manning  Requirements 

\ 

/ 

Common  disciplines  are  required, 
although  mission  structure  may  be 
significantly  different  This  task 
can  be  combined  and  enlarged  to 
include  cross-traimng 

01-02-01-03 

Computer  Utilization  Plan 

/ 

Basic  ground  rules  for  computer 
utilization  should  apply  to  both 
programs 
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Table  102.0-1  Comparison  of  Space  Tug  and  IUS  Operational  Elements  (Continued) 


WBS  320-  OR  XXX- 

TITLE 

C 

TU 

IU 

M 

COMMENTS 

01-02-01-04 

Maintenance  Schedule 

/ 

/ 

General  maintenance  policy  will  be  a 
shared  task.  Maintenance  of  Tug- 
umque  hardware  (e  i , television 
equipments)  will  require  modification 
of  the  plan. 

01-02-01-05 

Hire  Control  and  Support  Staff 

/ 

The  same  staff  should  be  utilized  by 
both  IUS  and  Space  Tug  programs. 

10-02-02 

Console  Organization 

/ 

Console  organization  should  be  frozen 
early  and  carried  through  Tug 

10-02-01 

Design  Network  Interface 

/ 

/ 

Equipment  selected  should  be  suffi- 
ciently flexible  to  encompass  both 
IUS  and  Space  Tug  interface  con- 
straints. 

15-03-01 

Estimate  Ground  Software  Size 

/ 

This  task  must  size  for  the  maximum 
memory  and  speed  load  on  the  Data 
Processing  system  Thus  must  analyze 
both  IUS  and  Tug  programs 

02-04-02-01 

Select  Operational  Data  System 

✓ 

The  data  processing  system  should  be 
common  to  both  programs. 

07-04-01 

Install  Operational  Data  System 

/ 

Same  as  above 

06-06-01 

Size  Facility/Design  Physical 
Plant 

/ 

The  physical  plant  should  be  designed 
to  incorporate  both  program  require- 
ments without  subsequent  modification. 

06-06-02 

Construct  Physical  Plant 

/ 

A single  plant  construction  is 
desirable  and  cost-effective 
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Table  10  2 0-1.  Comparison  of  Space  Tug  and  /US  Operational  Elements  (Continued) 


WBS  320-  OR  XXX- 

TITLE 

C 

TU 

IU 

M 

COMMENTS 

07-04-02 

Install  Operational  Consoles 

/ 

Consoles  should  be  flexible  enough  to 
incorporate  both  IUS  and  Tug  require- 
ments with  only  minor  modification 

15-02-02-01 

Equation  Defining  Document 
Executi  ve/Tracking/Pl  anmng 
Software 

/ 

/ 

The  functions  of  the  executive  and 
mission  planning  software  are  independ- 
ent of  the  flight  vehicle  Tracking  is 
lUS-pecul lar. 

02-04-01-04 

Validation  Test  Requirements 
Fundamental  IUS  [Tug]  Ground 
Programs 

/ 

This  task  establishes  test  requirements 
against  common  software  and  thus  may  be 
merged  between  both  programs 

10-01-05-01 

Define  Ground  Network  Tracking 
Requirements 

/ 

Tracking  will  be  an  IUS  function. 
Space  Tug  navigation  will  be 
autonomous 

10-01-05-02 

Network  Tracking  Validation 
Procedures 

/ 

Procedures  to  test  the  tracking 
function  are  required 

10-03-01 

Network  Tracking  Validation  Tests 

/ 

The  test  is  unique  to  the  IUS  program. 

15-02-03-01 

Program  Ground  Tracking,  Planning 
and  Executive  Routines 

/ 

/ 

This  program  implements  the  software 
which  will  be  common  to  both  IUS  and 
Space  Tug  and  the  IUS  tracking 
software 

15-02-04-01 

Verify  Executive,  Tracking  and 
Planning  Software 

/ 

/ 

This  task  verifies  the  common  aspects 
of  the  ground  software  and  the 
IUS-pecul lar  tracking  software 

Table  10 JO-1.  Comparison  of  Space  Tug  and  /US  Operational  Elements  (Continued) 
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VIBS  320-  OR  XXX- 

TITLE 

C 

TU 

IU 

M 

COMMENTS 

01-02-01-06 

Obtain  the  IUS  [Space  Tug]  System 
Characteristics 

/ 

/ 

These  tasks  are  independent,  but  both 
must  be  accomplished  prior  to  the 
design  of  common  network  equipment 
and  common  console  utilization 

02-01-02 

IUS  [Tug]  Mission  Characterization 

/ 

/ 

These  tasks  are  independent,  but  both 
must  be  accomplished  prior  to  major 
planning  activities 

15-01-02-01 

Equation  Defining  Document  IUS 
[Space  Tug]  Flight  Program 

/ 

/ 

All  tasks  relative  to  flight  softv/are 
design,  development,  programming  and 
verification  are  vehicle  - driven 

15-02-02-02 

IUS  [Tug]  Downdata/Updata/ 
[Docking]  and  Simulation  Ground 

/ 

/ 

These  tasks  are  vehicle  updata, 
downdata  and  configuration  dependent 

02-0^-01-05 

IUS  [Tug]  Ground  Validation  Test 
Pequi rements 

/ 

/ 

These  tasks  are  vehicle  updata, 
downdata  and  configuration  dependent 

02-01-03 

Determine  IUS  [Tug]  Failure  Modes 

/ 

/ 

These  tasks  are  vehicle  configuration 
dependent 

10-02-03 

IUS  [Tug]  Display  Format  Design 

/ 

/ 

v' 

These  tasks  are  vehicle  updata, 
downdata  and  configuration  dependent 
eycept  in  the  flight  dynamics 
discipline 

10-01-02 

IUS  [Tug]  Mission  Failure  Effects 
Analysis 

/ 

/ 

These  tasks  are  vehicle  and  mission 
configuration  dependent 
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Table  10 JO-1  Comparison  of  Space  Tug  and  /US  Operational  Elements  (Continued) 


VIBS  320-  OR  XXX- 

TITLE 

C 

TU 

IU 

M 

COMMENTS 

05-02-03-03 

Design  IUS  [Tug]  Mission  Simulation 

/ 

/ 

These  tasks  are  vehicle  and  mission 
configuration  dependent. 

10-01-03 

Analyze  IUS  [Tug]  Component 
Characteristics 

/ 

/ 

These  tasks  are  vehicle  configuration 
dependent 

05-02-03-01 

IUS  [Tug]  Training  Requirements, 
Evaluation  Criteria  and  Simulation 
Schedule 

/ 

/ 

/ 

These  tasks  are  vehicle  and  mission 
configuration  dependent,  but  have 
common  underlying  human  factor 
considerations 

10-01-04-01 

Prepare  IUS  [Tug]  System  Handbook 

/ 

/ 

These  tasks  are  vehicle  configuration 
and  performance  dependent. 

10-01-04-02 

Publish  and  Update  IUS  [Tug] 
System  Handbook 

/ 

/ 

These  tasks  are  vehicle  configuration 
and  performance  dependent. 

05-02-03-02 

Develop  IUS  [Space  Tug]  Training 
Material 

/ 

/ 

These  tasks  are  vehicle  downdata, 
updata,  configuration  and  mission 
dependent. 

05-02-03-04 

IUS  [Space  Tug]  Classroom  Training 

/ 

/ 

These  tasks  are  vehicle  downdata, 
updata,  configuration  and  mission 
dependent 

10-01-05-03 

IUS  [Space  Tug]  Network  Data 
Handling  Requirements 

/ 

/ 

These  tasks  are  vehicle  updata  and 
downdata  dependent. 

10-01-05-04 

IUS  [Tug]  Network  Data  Validation 
Procedures 

✓ 

/ 

These  tasks  are  vehicle  updata  and 
downdata  dependent 

10-03-02 

IUS  [Space  Tug]  Network  Validation 
Tests 

/ 

/ 

These  tasks  are  vehicle  updata  and 
downdata  dependent. 
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Table  102.0-1.  Comparison  of  Space  Tug  and  IUS  Operational  Elements  ( Continued } 


VJBS  320-  OR  XXX- 

TITLE 

C 

TU 

IU 

M 

COMMENTS 

15-02-03-02 

Program  IUS  [Space  Tug]  Downdata/ 
Updata/[Docking]/Simulation  System 

/ 

/ 

These  tasks  are  vehicle  update, 
downdata  and  configuration  dependent. 

T5-02-04-02 

Verify  IUS  [Tug]  Downdata/Updata/ 
[Docking]/Simul ation  Programs 

/ 

/ 

These  tasks  are  vehicle  updata, 
dov/ndata  and  configuration  dependent. 

02-04-01-02 

IUS  [Tug]  Console  Position  Guide- 
lines 

/ 

This  task  will  be  executed  once  for 
the  IUS  program,  then  modified  for 
Space  Tug  implementation,  based  upon 
IUS  experience. 

02-04-03-01 

IUS  [Tug]  Mission  Planning  and 
Optimization 

/ 

/ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug. 

10-01-01 

Develop  IUS  [Tug]  Procedures  and 
Rules 

/ 

/ 

These  tasks  are  vehicle  and  mission 
dependent. 

02-04-03-02 

IUS  [Tug]  Abort  Planning 

/ 

J 

This  task  is  unique  for  each  mission. 

01-02-01-08 

IUS  [Space  Tug]  Interagency 
Coordination 

/ 

/ 

/ 

This  task  continues  from  IUS  through 
Space  Tug  operations  and  involves 
program  support  documentation 

15-01-02-03 

IUS  [Space  Tug]  Flight  Program 
Verification 

/ 

/ 

This  task  is  vehicle  and  mission 
dependent 

01-02-01-07 

Prepare  IUS  [Tug]  Interagency 
Documentation 

/ 

/ 

/ 

This  task  continues  from  IUS  through 
Space  Tug  operations  and  involves 
program  support  documentation. 

15-02-05-01 

Program  IUS  [Tug]  Mission 
Simul ati on 

/ 

/ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug 
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Table  10.2.0-1  Comparison  of  Space  Tug  and  /US  Operaional  Elements  ( Continued ') 


V'BS  320-  OR  XXX- 

TITLE 

C 

TU 

IU 

M 

COMMENTS 

15-01-03-01 

IUS  [Tug]  Fission  Specific 
Equation  Defining  Document  (EDD) 

/ 

/ 

This  task  is  unque  for  each  mission 
flown  by  both  IUS  and  Tug 

lb-01-03-02 

IUS  [Tug]  Mission  Specific 
Programming 

/ 

/ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug. 

15-01-03-03 

IUS  [Tug]  Mission  Program 
Verification 

/ 

✓ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug 

05-02-03-05 

IUS  [Tug]  Mission  Simulation 
Training 

/ 

/ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug 

10-04 

Conduct  IUS  [Space  Tug]  Mission 
Operations 

/ 

/ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug. 

02-04-05-01 

IUS  [Space  Tug]  Post  Mission 
Reports 

✓ 

/ 

This  task  is  unique  for  each  mission 
flown  by  both  IUS  and  Tug. 

02-04-01-03 

Define  IUS  [Tug]  Operation 
Certification  Criteria 

/ 

/ 

/ 

This  task  is  mission  and  vehicle 
dependent,  but  also  involves 
underlying  common  human  factors 
considerations . 

10.3  INTEGRATED  SPACE  TUG/IUS  OPERATIONAL  ELEMENTS 

Table  10  3.0-1  presents  the  composite  integrated  Space  Tug/IUS  work  Break- 
down structure  Where  common  UBS  elements  were  found,  the  integrated 

structure  retains  the  "320-"  designation,  since  Space  Tug  is  to  be  the 
long-duration  surviving  program.  Similarly,  the  higher  elements  in 
the  structure  (combinations  of  "products")  retain  the  "320-"  prefix 

Table  10.3  0-2  presents  the  modified  WBS  dictionary  for  the  composite 
Space  Tug/IUS  program 
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Table  10.3J0-1.  Composite  Integrated  Space  Tug/I US  VJork  Breakdown  Structure 
VJBS  Identification  Number,  Sequence 


IDENTIFICATION  NUMBER 

ELEMENT 

LEVEL 

320 

SPACE  TUG  PROJECT 

3 

320-01 

Project  Management 

4 

320-01-01 

Cost/Performance  Management 

5 

320-01-01-01 

Cost  Control  System 

5 

320-01-01-02 

Schedule  Control  System 

6 

320-01-02 

Project  Direction 

5 

320-01-02-01 

Development  Management 

6 

320-01-02-01-01 

Contract  Software  Development 

7 

320-01-02-01-02 

Plan  Facility  Utilization 

7 

320-01-02-01-03 

Computer  Utilization  Plan 

7 

320-01-02-01-04 

Maintenance  Schedule 

7 

320-01-02-01-05 

Hire  Control  and  Support  Staff 

7 

320-01-02-01-06 

Obtain  Space  Tug  System  Characteristics 

7 

320-01-02-01-07 

Prepare  Tug  Interagency  Documents 

7 

320-01-02-01-08 

Tug  Interagency  Coordination 

7 

XXX-01 -02-01 -06 

Obtain  IUS  System  Characteristics 

7 

XXX-01-02-01-07 

Prepare  IUS  Interagency  Documents 

7 

XXX-01-02-01-08 

IUS  Interagency  Coordination 

7 

320-01-02-02 

Quality  Management 

6 

320-01-02-03 

Logistics  Management 

6 

320-01-02-04 

Engineering  Administration 

6 

320-01-03 

Information  Management 

6 

320-02 

Systems  Engineering 

4 

320-02-01 

lUS/Tug  Systems  Engineering 

5 

320-02-01-01 

Master  Launuh  Schedule  Analysis 

6 

320-02-01-02 

Tug  Mission  Characterization 

6 

320-02-01-03 

Determine  Tug  Failure  Modes 

6 

XXX-02-01-02 

IUS  Mission  Characterization 

6 

XXX-02-01-03 

Determine  IUS  Failure  Modes 

6 

320-02-02 

Shuttle  Interface 

5 

320-02-03 

Payload  Interface 

5 

320-02-04 

Sustaining  Engineering 

5 

320-02-04-01 

Flight  Control  Engineering 

6 

320-02-04-01-01 

Mission  Phase  Manning  Requirements 

7 

320-02-04-01-02 

Tug  Console  Position  Guidelines 

7 

320-02-04-01-03 

320-02-04-01-04 

Define  Tug  Operator  Certification/Criteria  7 
Common  Ground  Software  Validation  Test 
Requirements  7 

320-02-04-01-05 

Tug  Ground  Validation  Test  Requirements 

7 

XXX-02-04-01-05 

IUS  Ground  Validation  Test  Requirements 

7 

XXX-02-04-01-02 

IUS  Console  Position  Guidelines 

7 

XXX-02-04-01-03 

Define  IUS  Operator  Certification/Criteria  7 

320-02-04-02 

Flight  Support  Engineering 

6 

320-02-04-02-01 

Select  Operational  Data  System 

7 
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IDENTIFICATION  NUMBER 

ELEMENT  i 

LEVEL 

320-02-04-03 

Mission  Engineering 

6 

320-02-04-03-01 

Tug  Mission  Planning  and  Optimization 

7 

320-02-04-03-02 

Tug  Abort  Planning 

7 

XXX-02-04-03-01 

IUS  Mission  Planning  and  Optimization 

7 

XXX-02-04-03-02 

IUS  Abort  Planning 

7 

320-02-04-05 

Mission  Evaluation  Engineering 

6 

320-02-04-05-01 

Tug  Post  Mission  Reports 

7 

XXX-02-04-05-01 

IUS  Post  Mission  Reports 

7 

320-03 

Tug  Vehicle  Mam  Stage 

4 

320-05 

Logistics 

4 

320-05-01 

Transportation  and  Handling 

5 

320-05-02 

Training 

5 

320-05-02-01 

Simulators  and  Equipment 

6 

320-05-02-02 

Ground  Crew  Training 

6 

320-05-02-03 

Flight  Operations  Crew  Training 

6 

320-05-02-03-01 

Tug  Training  Requirement/Critena/Simsked 

7 

320-05-02-03-02 

Develop  Tug  Training  Material 

7 

320-05-02-03-03 

Design  Tug  Mission  Simulation 

7 

320-05-02-03-04 

Tug  Classroom  Training 

7 

320-05-02-03-05 

Tug  Mission  Simulation  Training 

7 

XXX-05-02-03-01 

IUS  Training  Requirement/Critena/Simsked 

7 

XXX-05-02-03-02 

Develop  ’IDS  Training  Material 

7 

XXX-05-02-03-03 

Design  IUS  Mission  Simulation 

7 

XXX-05-02-03-04 

IUS  Classroom  Training 

7 

XXX-05-02-03-05 

IUS  Mission  Simulation  Training 

7 

320-06 

Facilities 

4 

320-06-01 

Manufacturing 

5 

320-06-02 

Test 

5 

320-06-03 

Maintenance  and  Refurbishment 

5 

320-06-04 

ETR  Launch 

5 

320-06-05 

WTR  Launch 

5 

320-06-06 

Flight  Operations  Facility 

5 

320-06-06-01 

Size  Facility/Design  Physical  Plant 

6 

320-06-06-02 

Construct  Physical  Plant 

6 

320-07 

Ground  Support  Equipment  (GSE) 

4 

320-07-01 

Manufacturing  and  Test  GSE 

5 

320-07-02 

Eastern  Test  Range  GSE 

5 

320-07-03 

Western  Test  Range  GSE 

5 

320-07-04 

Flight  Operations  GSE 

5 

320-07-04-01 

Install  Operational  Data  System 

6 

320-07-04-02 

Install  Operational  Consoles/Hardware 

6 

320-08 

Vehicle  Test 

4 

320-09 

Launch  Operations 

4 

320-10 

Flight  Operations 

4 

320-10-01 

Mission  Planning  and  Documentation 

5 

320-10-01-01 

Develop  Tug  Procedures  and  Rules 

6 

XXX-10-01-01 

Develop  IUS  Procedures  and  Rules 

6 

320-10-01-02 

Tug  Mission  Failure  Effects 

6 

XXX-10-01-02 

IUS  Mission  Failure  Effects 

6 

320-10-01-03 

Analyze  Tug  Component  Characteristics 

6 

XXX-10-01-03 

Analyze  IUS  Component  Characteristics 

6 
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Table  10.3  0-1  Composite  Integrated  Space  Tug/IUS  Work  Breakdown  Structure 
MBS  Identification  Number  Sequence  (Continued) 


IDENTIFICATION  NUMBER 

ELEMENT 

LEVEL 

320-10-01-04 

Flight  Control  Systems  Handbook 

6 

320-10-01-04-01 

Prepare  Tug  Systems  Handbook 

7 

320-10-01-04-02 

Publish/Update  Tug  Systems  Handbook 

7 

XXX- 1 0-01  -04-01 

Prepare  IUS  Systems  Handbook 

7 

XXX-10-01 -04-02 

Publish/Update  IUS  Systems  Handbook 

7 

320-10-01-05 

Tug  Network  Interface  Documentation 

6 

XXX-10'01-05-01 

Define  Network  Tracking  Requirements 

7 

XXX- 1 0—01 -05-02 

Network  Tracking  Validation  Procedures 

7 

320-10-01-05-03 

Tug  Network  Data  Handling  Requirements 

7 

320-10-01-05-04 

Tug  Network  Data  Validation  Procedures 

7 

XXX-10-01 -05-03 

IUS  Network  Data  Handling  Requirements 

7 

XXX-10-01-05-04 

IUS  Network  Data  Validation  Procedures 

7 

320-10-02 

Operational  Preparations 

5 

320-10-02-01 

Design  Network  Interface  System 

6 

320-10-02-02 

Console  Organization 

6 

320-10-02-03 

Tug  Display  Format  Design 

6 

XXX-10-02-03 

IUS  Display  Format  Design 

6 

320-10-03 

Mission  Readiness  Testing 

5 

XXX-10-03-01 

Network  Tracking  Validation  Tests 

6 

320-10-03-02 

Tug  Network  Validation  Tests 

6 

XXX-10-03-02 

IUS  Network  Validation  Tests 

6 

320-10-04 

Conduct  Tug  Mission  Operations 

5 

XXX- 10-04 

Conduct  IUS  Mission  Operations 

5 

320- n 

Refurbishment  and  Integration 

4 

320-15 

Software 

4 

320-15-01 

Flight  Software 

5 

320-15-01-01 

Plan  Flight  Software  Development 

6 

320-15-01-02 

Baseline  Flight  Program  Development 

6 

320-15-01-02-01 

EDD  - Tug  Flight  Program 

7 

320-15-01-02-02 

Program  Tug  Flight  Software 

7 

320-15-01-02-03 

Tug  Flight  Program  Verification 

7 

XXX-15-01-02-01 

EDD  - IUS  Flight  Program 

7 

XXX-1 5-01 -02-02 

Program  IUS  Flight  Software 

7 

XXX-15-01 -02-03 

IUS  Flight  Program  Verification 

7 

320-15-01-03 

Mission  Specific  Program  Modification 

6 

320-15-01-03-01 

Tug  Mission  Specific  EDD 

7 

320-15-01-03-02 

Tug  Mission  Specific  Program 

7 

320-15-01-03-03 

Tug  Mission  Program  Verification 

7 

XXX-1 5-01 -03-01 

IUS  Mission  Specific  EDD 

7 

XXX-15-01 -03-02 

IUS  Mission  Specific  Program 

7 

XXX-15-01-03-03 

IUS  Mission  Program  Verification 

7 

320-15-02 

Ground  Software 

5 

320-15-02-01 

Plan  Ground  Software  Development 

6 

320-15-02-02 

Equation  Definition 

6 

320-15-02-02-01 

EDD  - Executi ve/Trackmg/PI anmng 

7 

320-15-02-02-02 

EDD  - Tug  Dndata/Updata/Docking/Sim 

7 

XXX-15-02-02-02 

EDD  - IUS  Dndata/Updata/Sim 

7 

320-15-02-03 

Programming 

6 
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Table  10.3.0-1  Composite  Integrated  Space  Tug/lUS  Work  Breakdown  Structure 
IVBS  Identification  Number  Sequence  (Continued) 

IDENTIFICATION  NUMBER  ELEMENT  LEVEL 

320-15-02-03-01  Program  Ground  EX/TK/Planmng  SW 

320-15-02-03-02  Program  Tug  Dndata/Updata/Docking/Sim 

XXX-1 5-02-03-02  Program  IUS  Dndata/Updata/Sim 

320-15-02-04  Program  Verification 

320-15-02-04-01  Verify  Executive/TK/Planmng  SW 

320-15-02-04-02  Verify  Tug  Dndata/Updata/Docking/Sim 

XXX-1 5-02-04-02  Verify  IUS  Dndata/Updata/Sim 

320-15-02-05  Mission  Specific  Simulation 

320-15-02-05-01  Program  Tug  Mission  Simulation 

XXX-1 5-02-05-01  Program  IUS  Mission  Simulation 

320-15-03  Computer  Selection  Support 

320-15-03-01  Estimate  Ground  Software  Size 

320-16  Orbiter  Interface 
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320  SPACE  TUG  PROJECT 

This  element  summarizes  the  direct  and  indirect  (G&A  and  burden)  effort  to 
provide  hardware,  software,  services,  and  facilities  that  are  required  to 
develop,  produce,  operate,  and  maintain  a Space  Tug  Project,  including  the 
'associated  Tug/Shuttle  interfaces 

320-01  PROJECT  MANAGEMENT 

This  element  summarizes  the  management  activities  of  planning,  organizing, 
directing,  coordinating,  controlling  and  approval  actions  required  to 
accomplish  overall  Space  Tug  Project  objectives  which  are  not  associated  with 
specific  hardware  elements 

320-01-02  PROJECT  DIRECTION 

This  element  pertains  to  the  continuous  monitoring  of  all  functional  manage- 
ment disciplines  to  provide  central  direction  and  control  of  the  overall 
project  Included  are  the  decision  making  for  management,  timely  resolution 
of  problem  areas  to  meet  established  schedules,  and  overall  surveillance  of 
project  progress  and  goals. 

320-01-02-01  DEVELOPMENT  MANAGEMENT 

-This  element  includes  those  tasks  which  require  external  contractual  inter- 
faces, interagency  interfaces  and  inter-center  interfaces  to  be  accomplished 
It  also  includes  direction  of  sensitive  development  tasks  which  require 
project  level  stature  to  insure  proper  evecution 

320-01-02-01-01  CONTRACT  SOFTWARE  DEVELOPMENT 

This  task  includes  all  effort  necessary  to  prepare  a Statement  of  Work, 
evaluate  proposals  and  provide  financial,  contracting  and  procurement  support 
'in  order  to  place  an  outside  contractor  under  contract  for  development  of 
ground  and  flight  software 

320-01-02-01-02  PLAN  FACILITY  UTILIZATION 

This  task  includes  all  efforts  involved  in  establishing  a coherent  plan  for 
the  utilization  of  a Mission  Control  facility  This  will  include  such  things 
as  scheduling  of  activities,  program  sharing,  office,  canteen,  technical 
support  area  and  other  generic  requirements  which  impact  facility  design 

320-01-02-01-03  COMPUTER  UTILIZATION  PLAN 

This  task  includes  all  efforts  required  to  develop  and  enforce  a plan  to 
maximize  the  utilization  of  the  computational  facility  incorporated  in  the 
IUS/Tug  ground  control  complex  This  will  include  a pre-emption  hierarchy, 
mission  planning  schedule,  mission  operation  schedule,  batch  processing 
schedule,  etc 
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320-01-02-01-04  MAINTENANCE  SCHEDULE 

This  task  establishes  the  housekeeping  and  periodic  maintenance  requirements 
of  the  control  center  and  associated  equipments  This  task  includes  the 
contracting  for,  and  administration  of,  specific  external  maintenance  of  the 
data  system,  plant  environmental  control  mechanisms,  and  janitorial  services. 
Periodic  and  specific  maintenance  of  the  flight  control  and  flight  support 
console  items  will  be  conducted  by  the  permanent  party  flight  support  staff. 

320-01-02-01-05  HIRE  CONTROL  AND  SUPPORT  STAFF 

This  task  includes  all  efforts  required  to  procure  competent  personnel  to 
perform  flight  control  tasks  in  the  technical  disciplines  of  propulsion, 
avionics,  networks,  communication,  guidance,  dynamics,  data  selection,  tele- 
vision, and  docking.  It  also  includes  the  efforts  required  to  hire  flight 
support  personnel  in  the  technical  disciplines  of  facility  supervisor,  data 
systems,  maintenance  operations  and  software  support 

320-01-02-01-06  OBTAIN  SPACE  TUG  5YSTEM  CHARACTERISTICS 

This  task  includes  all  efforts  necessary  to  acquire,  catalog,  define  and 
analyze  the  operational  characteristics  of  the  Space  Tug  system  The  output 
of  this  task  is  utilized  in  the  development  of  flight  controller  display 
designs,  network  telemetry  and  updata  interface  systems  design,  and  as  primary 
input  into  the  determination  of  operational  failure  modes 

XXX-01-02-01-06  OBTAIN  IUS  SYSTEM  CHARACTERISTICS 


This  task  includes  all  efforts  necessary  to  acquire,  catalog,  define  and 
analyze  the  operational  characteristics  of  the  IUS  system.  The  output  of 
this  task  is  utilized  in  the  development  of  flight  controller  display  designs, 
network  telemetry  and  updata  interface  system  design,  and  as  primary  input 
into  the  determination  of  operational  failure  modes. 

320-01-02-01-07  PREPARE  TUG  INTERAGENCY  DOCUMENTATION 

This  task  includes  all  efforts  required  to  prepare  interagency  and  mtercenter 
coordination  documents,  a ground  support  plan  and  documents  which  levy 
requirements  on  other  government  agencies  or  other  NASA  centers  The  output 
of  this  task  is  required  for  the  interagency  coordination  task. 

320-01-02-01-08  SPACE  TUG  INTERAGENCY  C00RDTNATI0N 

This  task  includes  all  efforts  required  to  establish  mutual  agreements  with 
DoD  and  NASA  centers  supporting  Space  Tug  mission  operations.  This  includes 
the  coordination  of  program  support  requirements  and  ground  support  planning 

XXX-01-02-01-08  IUS  INTERAGENCY  COORDINATION 

This  task  includes  all  efforts  required  to  establish  mutual  agreements  with 
DoD  and  NASA  centers  supporting  the  IUS  mission  operations  This  includes 
the  coordination  of  program  support  requirement  and  ground  support  planning 
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320-01-02-01-09  SPACE  TUG  NETWORK  RENTAL 

This  element  includes  the  cost  of  purchasing  network  services  (Telemetry 
Data,  Command  Data,  Television  Image)  from  the  data  support  network 

XXX-01-02-01-09  IUS  NETWORK  RENTAL 

This  element  includes  the  cost  of  purchasing  network  servcies  (Telemetry 
Data,  Command  Data,  Tracking  Data)  from  the  data  support  network 

320-02  SYSTEMS  ENGINEERING 

This  element  summarizes  the  Space  Tug  systems  engineering  task  of  directing 
and  controlling  a totally  integrated  engineering  effort,  including  require- 
ments analysis  and  integration,  system  definition,  system  test  definition, 
interfaces,  safety,  reliability,  maintainability,  configuration  management, 
quality  engineering,  technology  utilization  and  logistics  support  analysis 

320-02-01  I US/TUG  SYSTEMS  ENGINEERING 

This  element  consists  of  the  systems  engineering  and  integration  effort  to 
design,  develop,  produce  and  test  the  Space  Tug  and  associated  Tug/Shuttle 
interfaces  Included  are  analyses  required  to  verify  compatibility  of  designs 
with  requirements,  to  meet  mission  model  requirements,  to  control  and  direct 
the  engineering  activities,  to  assure  proper  Space  Tug  systems  integration 
with  both  the  Shuttle  and  spacecraft,  and  to  make  cost/performance  tradeoffs 
Also  included  are  engineering  planning,  studies,  technology  utilization, 
technical  risk  assessment,  reliability  engineering,  safety  engineering, 
quality  control,  configuration  requirements  analysis,  and  associated  support 
required  to  perform  the  Tug  systems  engineering  task  Logistics  planning 
and  management  are  also  included 

320-02-01-01  MASTER  LAUNCH  SCHEDULE  ANALYSIS 

The  master  Launch  Schedule  will  be  analyzed  to  determine  the  type,  spacing, 
and  frequency  of  both  IUS  and  Space  Tug  flight  This  task  will  establish  the 
range  of  mission  types,  trajectories,  payload  accommodations  and  control 
facility  utilization  requirements  across  the  IUS/Space  Tug  operational  period 
This  task  is  a predecessor  to  the  establishment  of  Tug  mission  characteristics, 
IUS  mission  characteristics  and  control  facility  utilization  planning 

320-02-01-02  1UG  MISSION  CHARACTERIZATION 

This  task  accepts  the  output  of  the  master  launch  schedule  analysis  task  and 
operates  on  that  output  in  order  to  determine  the  specific  characteristics 
of  all  defined  Space  Tug  missions  The  output  of  this  task  is  utilized  in 
the  determination  of  mission  phase  manning  requirements,  definition  of  Space 
Tug  operator  certification  (and  criteria  for  certification),  a computer 
utilization  plan  for  the  Space  Tug  portion  of  the  Shuttle  era  and  the 
associated  maintenance  schedule 

XXX-02-01-02  IUS  MISSION  CHARACTERIZATION 

This  task  accepts  the  output  of  the  master  launch  schedule  analysis  tasks 
and  operates  on  that  output  in  order  to  determine  the  specific  characteristics 
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of  all  defined  IUS  missions  The  output  of  this  task  is  utilized  in 
the  determination  of  mission  phase  manning  requirements,  definition  of  IUS 
operator  certification  (and  criteria  for  certification),  a computer  utiliza- 
tion plan  for  the  IUS  portion  of  the  Shuttle  era  and  the  associated 
maintenance  schedule 

320-02-01-03  DETERMINE  TUG  FAILURE  MODES 

After  the  Space  Tug  system  characteristics  have  been  obtained,  categorized 
and  defined,  the  systems  will  be  analyzed  for  high  probability  failure  modes 
The  output  of  this  task  will  be  a list  of  potential  failures,  which  can  impact 
the  operational  performance  of  the  vehicle  Failures  of  a cosmetic  nature 
will  not  be  considered  The  output  of  this  task  is  a list  of  high  probability 
failure  modes  which  will  then  be  analyzed  for  the  overall  mission  effect  of 
that  failure 

XXX-02 -01-03  DETERMINE  IUS  FAILURE  MODES 

After  the  IUS  system  characteristics  have  been  obtained,  categorized  and 
defined,  the  systems  will  be  analyzed  for  high-probability  failure  modes. 

The  output  of  this  task  will  be  a list  of  potential  failures  which  can  impact 
the  operational  performance  of  the  vehicle.  Failures  of  a cosmetic  nature 
will  not  be  considered  The  output  of  this  task  is  a list  of  high  probability 
failure  modes  which  will  then  be  analyzed  for  the  overall  mission  effort  of 
that  failure 

320-02-04  SUSTAINING  ENGINEERING 

This  element  consists  of  sustaining  engineering  effort  required  for  the  Space 
Tug  and  associated  Tug/Shuttle  interfaces  after  the  completed,  assembled  Tug 
and  interface  subsystems  have  been  checked  out  for  full  flight  certification 
and  delivered  A principal  effort  includes  normal  product  improvement  and 
engineering  changes  that  may  occur  as  a result  of  user  recommendations  and/or 
operational  experience  Also  included  are  in-plant  engineering  liaison 
support  of  operational  activities  and  the  sustaining  engineering  support 
required  during  the  operations  phase.  Activities  would  include  further 
allocation  of  performance  requirements  for  the  vehicle  into  subsystem  require- 
ments, evaluation  of  vehicle  and  GSE  performance,  maintainability  analysis, 
etc  Excluded  are  those  activities  that  pertain  to  major  hardware  modifi- 
cation required  to  meet  new  performance  specifications 

320-02-04-01  FLIGHT  CONTROL  ENGINEERING 

This  task  includes  all  efforts  required  to  provide  real-time  assessment  of 
systems  status,  formulation  and  issuance  of  command  actions,  pre-mission 
preparation,  training  and  operator  certification. 

320-02-04-01-01  MISSION  PHASE  MANNING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  types  and  quantity 
of  personnel  required  to  support  both  IUS  and  Space  Tug  flight  control  and 
flight  support  activities.  It  will  include  an  analysis  of  the  mission  density, 
the  overlap  between  adjacent  modules  m the  mission  structure  and  will 
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establish  the  control  and  support  personnel  necessary  to  accomplish  the  IUS 
and  Space  Tug  missions  with  a minimum  loss  of  productive  man  hours  This 
task  will  also  include  the  plan  for  cross-training  mission  support  personnel 
as  the  IUS  phases  into  the  Space  Tug  era 

320-02-04-01-02  TUG  CONSOLE  POSITION  GUIDELINES 

This  task  includes  all  activities  required  to  establish  generic  position 
responsibilities  as  a function  of  console  and  technical  discipline  This 
activity  is  based  upon  the  mission  phase  manning  requirements  The  output 
is  utilized  as  one  input  to  the  mission  simulation  design  and  to  the  Space 
Tug  requirements  criteria,  simulation  and  schedule  tasks  The  output  of 
this  task  establishes  the  organizational  reporting  tree  and  authority  for 
both  technical  and  hierarchial  relationships. 

XXX-02-04-01-02  IUS  CONSOLE  POSITION  GUIDELINES 

This  task  includes  all  activities  required  to  establish  generic  position 
responsibilities  as  a function  of  console  and  technical  discipline  This 
activity  is  based  upon  the  mission  phase  manning  requirements  The  output 
is  utilized  as  one  input  to  the  mission  simulation  design  and  to  the  IUS 
requirements  criteria,  simulation  and  schedule  tasks  The  output  of  this 
task  establishes  the  organizational  reporting  tree  authority  for  both  tech- 
nical and  hierarchial  relationships. 

320-02-04-01-03  DEFINE  SPACE  TUG  OPERATOR  CERTIFICATION/CRITERIA 


This  task  includes  all  efforts  required  to  analyze  the  functions  of  the 
consoles  and  to  establish  appraisal  criteria  by  which  the  operator's  perfor- 
mance may  be  evaluated  As  with  all  real  time  operations,  console  operators 
must  demonstrate  the  ability  to  perform  well  under  stress  This  task  analyzes 
the  stress  situations  which  the  operator  will  face  and  establishes  the 
criteria  by  which  the  operator's  performance  and  technical  adequacy  are  to 
be  judged 

XXX-02-04-01-03  DEFINE  IUS  OPERATOR  CERTIFICATION/CRITERIA 

This  task  includes  all  efforts  required  to  analyze  the  functions  of  the 
consoles  and  to  establish  appraisal  criteria  by  which  the  operator's  perfor- 
mance may  be  evaluated  As  with  all  real  time  operations,  console  operators 
must  demonstrate  the  ability  to  perform  well  under  stress.  This  task  analyzes 
the  stress  situations  which  the  operator  will  face  and  establishes  the 
criteria  by  which  the  operator's  performance  and  technical  adequacy  are  to 
be  judged 

320-02-04-01-04  COMMON  GROUND  VALIDATION  TEST  REQUIREMENTS 


This  task  includes  the  establishment  of  proof-of-performance  parameters  for 
the  software  which  is  common  to  both  the  IUS  ground  operations  and  the  Space 
Tug  operations  This  task  establishes  the  vital  criteria  against  which 
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the  program  performance  is  to  be  evaluated,  and  should  be  conducted  inde- 
pendently of  the  Equation  Definition  generation 

320-02-04-01-05  TUG  GROUND  VALIDATION  TEST  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  criteria  for 
acceptance  or  rejection  of  Space  Tug  peculiar  ground  software.  This  task 
is  performed  independently  of  the  programming  effort  and  is  specifically 
to  establish  proof-of-performance  standards  against  which  the  program  will 
be  judged. 

XXX-02-01-05  IUS  GROUND  VALIDATION  TEST  REQUIREMENTS 

This  task  includes  all  efforts  required  to  establish  the  criteria  for  accep- 
tance or  rejection  of  IUS-peculiar  ground  software.  This  task  is  performed 
independently  of  the  programming  effort  and  is  specifically  to  establish 
proof-of-performance  standards  against  which  the  program  will  be  judged. 

320-02-04-02  FLIGHT  SUPPORT  ENGINEERING 

This  task  includes  all  efforts  required  to  provide  real-time  support  to 
Flight  Control  personnel,  maintain  operational  hardware  in  operable  condition, 
provide  network  interface  and  alternate  support  capability. 

320-02-04-02-01  SELECT  OPERATIONAL  DATA  SYSTEM 

This  task  includes  all  efforts  required  to  establish  the  integrated  require- 
ments of  an  operational  data  system  and  takes  into  account  the  ground 
software  size  estimate,  the  computer  utilization  plan,  and  growth  factors 
This  task  also  includes  all  procurement  and  purchase  operations  necessary 
in  the  buy  of  an  operational  data  system,  and  the  engineering  of  the  data 
system  configuration 

320-02-04-03  MISSION  ENGINEERING 

This  task  includes  all  efforts  to  plan  and  optimize  the  Space  Tug  or  IUS 
trajectory  under  nominal  mission  and  abort  conditions 

320-02-04-03-01  TUG  MISSION  PLANNING  AND  OPTIMIZATION 

This  task  is  iterative  and  includes  the  basic  design  of  trajectory,  timing 
of  burns,  and  error  propagation  analysis  leading  to  the  design  of  the  mission 
flight  plan  This  task  will  be  performed  on  the  operational  computer 
utilizing  software  specially  developed  for  the  purpose  The  output  of  this 
task,  and  the  output  from  the  associated  Space  Tug  abort  planning  task  are 
utilized  to  establish  the  mission  specific  deviations  from  the  Space  Tug 
flight  program  baseline,  and  to  provide  an  input  to  the  mission  specific 
simulation  development. 

XXX-02-04-03-01  IUS  MISSION  PLANNING  AND  OPTIMIZATION 

This  task  includes  the  basic  design  of  trajectory,  timing  of  burns,  and  error 
propagation  analysis  leading  to  the  design  of  the  mission  flight  plan  This 
task  will  be  performed  on  the  operational  computer  utilizing  software 
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specially  developed  for  the  purpose  The  output  of  this  task,  and  the  output 
from  the  associated  IUS  abort  planning  task  are  utilized  to  establish  the 
mission  specific  deviations  from  the  IUS  flight  program  baseline,  and  to 
provide  an  input  to  the  mission  specific  simulation  development 

320-02-04-03-02  TUG  ABORT  PLANNING 

After  the  basic  mission  planning  and  optimization  has  been  completed,  certain 
off- nominal  malfunction,  abort  and  contingency  conditions  must  be  investi- 
gated and  contingency  operational  procedures  developed  to  handle  those 
situations  This  task  utilizes  special  software  programmed  into  the  opera- 
tional computer  system  and  is  iterated  for  each  mission  The  output  of  this 
task  includes  alternative  mission  definitions,  abort  profiles,  and  degraded 
mission  plans  This  task  is  conducted  roughly  in  parallel  with  the  develop- 
ment of  Tug  procedures  and  mission  rules  in  order  that  cross  feed  between  the 
abort  planning  and  contingency  operational  planning  may  take  place 

XXX-20-04-03-02  IUS  ABORT  PLANNING 

After  the  basic  mission  planning  and  optimization  has  been  completed,  certain 
off-nominal  malfunction,  abort  and  contingency  conditions  must  be  investi- 
gated and  contingency  operational  procedures  developed  to  handle  those 
situations  This  task  utilizes  special  software  programmed  into  the 
operational  computer  system  and  is  iterated  for  each  mission  The  output  of 
this  task  includes  alternative  mission  definitions,  abort  profiles,  and 
degraded  mission  plans  This  task  is  conducted  roughly  in  parallel  with  the 
development  of  IUS  procedures  and  mission  rules  in  order  that  cross-feed 
between  the  abort  planning  and  contingency  operational  planning  may  take 
place. 

320-02-04-05  MISSION  EVALUATION  ENGINEERING 

This  task  includes  all  efforts  required  to  evaluate  vehicle  performance-to- 
design  analysis,  and  to  provide  comprehensive  feed-back  into  the  design 
modification  and  maintenance  programs  of  the  vehicles. 

320-02-04-05-01  SPACE  TUG  POST  MISSION  REPORTS 

This  task  includes  all  efforts  required  to  generate  three  post  mission 
reports  an  evaluation  and  critique  report  prepared  by  the  flight  controllers 
which  define  the  performance  of  the  vehicle  as  viewed  from  the  position  of 
a real  time  console  operator,  a maintenance  interface  report  prepai  ed  by  the 
flight  control  personnel  which  summarizes  the  observations  made  in  real  time 
which  imply  maintenance  requirements  against  the  flight  stage,  (this  report 
is  forwarded  to  the  launch  center  for  incorporation  in  the  Specific  Vehicle 
Maintenance  Plan),  a maintenance  and  operations  interface  report  which  eval- 
uates the  performance  of  the  data  gathering  and  tracking  network  during  the 
mission 

XXX-02-04-05-01  IUS  POST  MISSION  REPORTS 

This  task  includes  all  efforts  required  to  generate  two  post  mission  reports 
an  evaluation  and  critique  report  is  prepared  by  the  flight  controllers  which 
define  the  performance  of  the  vehicle  as  viewed  from  the  positions  of  a real 
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time  console  operator  and  a maintenance  and  operations  interface  report  which 
evaluates  the  performance  of  the  data  gathering  and  tracking  network  during 
the  mission 

320-05  LOGISTICS 

This  element  provides  the  effort  to  implement,  operate,  and  maintain  a 
logistics  management  for  support  of  the  Tug  and  Tug/Shuttle  interfaces  and 
related  ground  support  equipment,  including  transportation,  handling, 
factory  warehousing,  and  inventories,  systems  orientation,  and  familiariza- 
tion, training  of  ground  and  flight  crew  personnel  and  the  design, 
development  and  manufacture  of  those  distinctive  end-items  required 
specifically  to  meet  the  training  objectives  Included  are  operational 
maintenance  trainers,  cutav’ays,  models  and  any  facilities  constructed  or 
modified  for  training  purposes. 

320-05-02  TRAINING 

This  element  consists  of  training  services,  training  materials,  training  aids 
and  training  equipment  required  for  Tug  factory,  technical,  flight  and 
ground  crew  training  It  includes  instructor  and  student  services,  and  the 
development  and  maintenance  of  lesson  plans,  study  guides,  training  manuals, 
and  training  aids  for  classroom  and  trainer  instruction  in  preparation  for 
and  during  the  Tug  test  and  operations  program  phases 

320-05-02-03  FLIGHT  OPERATIONS  CREW  TRAINING 

This  element  includes  the  cost  of  instruction,  audio-visual  teaching  aids  and 
accessories  required  to  train  the  personnel  to  operate  the  Tug  and  equipment 
required  to  support  flight  operations  at  a flight  operations  center 

320-05-02-03-01  TUG  TRAINING  REQUIREMENTS,  EVALUATION  CRITERIA  AND 
SIMULATION  SCHEDULE 

This  task  accepts  as  inputs  the  Space  Tug  console  position  guidelines,  operator 
certification  criteria,  procedures  and  mission  rules  and  from  that  information 
creates  a requirement  for  training  criteria  against  which  successful  training 
is  judged,  a definition  of  kind  and  content  of  simulations  and  a schedule  for 
classroom,  and  simulation  training  for  a particular  mission  This  task  is  a 
recurring  task 

XXX-05-02-03-01  IUS  TRAINING  REQUIREMENTS,  EVALUATION  CRITERIA  ANO 
SIMULATION  SCHEDULE 

This  task  accepts  as  input  the  IUS  console  position  guidelines,  operator 
certification  criteria,  procedures  and  mission  rules  and  from  that  infor- 
mation creates  a requirement  for  training  criteria  against  which  successful 
training  is  judged,  definition  of  kind  and  content  of  simulations  and  a 
schedule  for  classroom,  and  simulation  training  for  a particular  mission. 

This  task  is  a recurring  task. 
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320-05-02-03-02  DEVELOP  SPACE  TUG  TRAINXNC  MATERIAL 

This  task  includes  the  development  and  preparation  of  all  materials  required 
for  classroom  training  of  flight  controllers  and  flight  support  personnel 
This  includes  text  books,  handouts,  view  graphs,  reference  material,  etc 

XXX-05-02-03-02  DEVELOP  IUS  TRAINING  MATERIAL 

This  task  includes  the  development  and  preparation  of  all  materials  required 
for  classroom  training  of  flight  controllers  and  flight  support  personnel 
This  includes  text  books,  handouts,  view  graphs,  reference  material,  etc 

320-05-02-03-03  DESIGN  TUG  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  integrate  the  results  of  the  Space 
Tug  procedures  and  rules,  the  optimum  and  abort  mission  timelines,  and 
operator  training  criteria  into  a Tug  mission  specific  simulation  design 
This  task  will  be  accomplished  both  in  the  DDT&E  phase  and  in  the  recurring 
phase  of  the  Space  Tug  program  A specific  simulation  design  will  be  form- 
ulated for  each  mission  The  flight  controller  and  flight  support  personnel 
will  be  trained  against  the  mission  specific  simulation  in  preparation  for 
their  operational  roles,  the  output  of  this  task  is  a set  of  malfunctions, 
predicted  responses  and  operator  performance  evaluation  criteria 

XXX-05-02-03-03  DESIGN  IUS  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  integrate  the  results  of  the  IUS 
procedures  and  rules,  the  optimum  and  abort  mission  timelines,  and  operator 
training  criteria  into  an  IUS  mission  specific  simulation  design  This  task 
will  be  accomplished  both  in  the  DDT&E  phase  and  in  the  recurring  phase  of 
the  IUS  program  A specific  simulation  design  will  be  formulated  for  each 
mission  The  flight  control  and  flight  support  personnel  will  be  trained 
against  the  mission  specific  simulation  in  preparation  for  their  operational 
roles.  The  output  of  this  task  is  a set  of  malfunctions,  predicted  responses 
and  operator  performance  evaluation  criteria 

320-05-02-03-04-  SPACE  TUG  CLASSROOM  TRAINING 

This  task  includes  the  instructor's  time,  student's  time,  and  the  facilities 
required  for  conducting  classroom  training  in  the  characteristics  of  a Space 
Tug  vehicle,  the  mission,  and  support  networks  Training  will  be  conducted 
by  flight  control  and  flight  support  personnel  in  addition  to  then  normal 
operational  tasks 

XXX-05-02-03-04  IUS  CLASSROOM  TRAINING 

This  task  includes  the  instructor's  time,  student's  time,  and  the  facilities 
required  for  conducting  classroom  training  in  the  characteristics  of  an  IUS 
vehicle,  the  mission,  and  support  networks  Training  will  be  conducted  by 
flight  control  and  flight  support  personnel  in  addition  to  their  normal 
operational  tasks 
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320-05-02-03-05  TUG  MISSION  SIMULATION  TRAINING 

This  task  includes  the  simulation  of  the  specific  Space  Tug  mission  for 
nominal  and  contingency  performance  cases  wherein  the  flight  support 
personnel  conduct  the  simulation  and  the  flight  control  personnel  are  judged 
on  their  ability  to  respond  to  contingency  situations  and  to  recognize  nom- 
inal vehicle  performance.  This  task  is  iterative  and  must  be  repeated  prior 
to  each  flight 

XXX-05-02-03-05  IUS  MISSION  SIMULATION  TRAINING 

This  task  includes  the  simulation  of  the  specific  IUS  mission  for  nominal 
and  contingency  performance  cases  wherein  the  flight  support  personnel 
conduct  the  simulation  and  the  flight  control  personnel  are  judged  on  their 
ability  to  respond  to  contingency  situations  and  to  recognize  nominal  vehicle 
performance  This  task  is  iterative  and  must  be  repeated  prior  to  each 
flight. 

320-06  FACILITIES 

This  element  covers  facilities  (new  or  modification  to  existing)  for  manu- 
facture, test,  maintenance,  refurbishment,  and  support  of  an  operational 
program  Note  that  the  basic  launch  and  operations  facilities  are  charged 
to  the  Shuttle  However,  those  facilities  built  specifically  for  Tug  and 
Tug/ Shuttle  interfaces  are  included  here  This  effort  includes  facilities 
planning,  acquisition  or  modification,  and  maintenance  Amortization  of 
adequate  existing  facilities  will  not  be  included 

320-06-06  FLIGHT  OPERATIONS  FACILITY 

This  element  covers  development  of  a new  facility  for  flight  control  support 
of  the  IUS  and  Space  Tug  programs.  This  effort  includes  facility  planning, 
acquisition,  modification  and  maintenance 

320-06-06-01  SIZE  FACILITY/DESIGN  PHYSICAL  PLANT 

Prior  to  beginning  this  task,  the  operational  data  system  will  have  been 
selected,  the  network  interface  design  will  have  been  completed  and  equipment 
selected,  and  the  console  equipment  designed  and  ordered  This  task  includes 
the  architectural  design  of  the  facility. 

320-06-06-02  CONSTRUCT  PHYSICAL  PLANT 

This  task  includes  the  effort  involved  by  a building  contractor  to  perform 
site  preparation,  construction  of  a physical  plant,  environmental  control  and 
electrical  installations  on  the  structure. 

320-06-06-03  PLANT  MAINTENANCE 

This  task  includes  all  contracted  services  for  the  maintenance  of  the  facility 
interior  and  exterior,  including  refuse,  janitorial  services,  structural, 
electrical,  mechanical  and  paint  maintenance  Also  included  are  utility 
costs. 
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320-07  GROUND  SUPPORT  EQUIPMENT  (65E) 

This  element  includes  all  GSE  required  for  the  Tug  and  Tug/Shuttle  interface 
subsystems  test  and  operations  Included  are  all  ground-based  equipment 
required  to  support  the  ground  test  program  and  launch,  recovery  and  main- 
tenance phases  during  flight  test  operations  and  flight  operations  The  GSE 
element  includes  design,  fabrication,  documentation,  and  qualification  of  Tug 
and  Tug/Shuttle  interface  peculiar  test  and  operational  GSE.  GSE  items 
included  are  hardware,  site  activiation,  and  maintenance  peculiar  to  inter- 
face ground  operations  for  manufacturing  and  launch. 

320-07-04  FLIGHT  OPERATIONS  GSE 

This  element  includes  all  ground-based  equipment  required  to  support  flight 
control  of  the  Space  Tug  during  both  flight  tests  and  operations  This 
element  also  includes  design,  modification,  fabrication,  integration,  docu- 
mentation, and  qualification  of  the  site.  Items  included  are  hardware,  site 
activiation,  and  maintenance 

320-07-04-01  INSTALL  OPERATIONAL  DATA  SYSTEM 

This  task  includes  all  efforts  by  the  data  system  contractor  to  install, 
diagnose  and  checkout  the  completed  data  system  installation  At  the  end 
of  this  task,  the  data  processing  system  will  be  on-line  and  operational, 
ready  to  support  future  data  processing  activities 

320-07-04-02  INSTALL  OPERATIONAL  CONSOLES 

This  task  includes  the  installation  of  the  console  hardware  and  associated 
interface  equipments  This  task  presumes  that  the  consoles  will  be  delivered 
to  the  finished  physical  plant  by  a vendor  and  then  will  be  installed  by 
flight  support  technicians 

320-07-04-03  DATA  SYSTEM  MAINTENANCE 

This  task  includes  contracted  services  for  the  maintenance,  diagnosis  and 
repair  of  the  operational  data  system  and  associated  peripheral  equipment. 
This  service  is  contracted  on  an  annual  basis 

320-10  FLIGHT  OPERATIONS 

This  element  includes  flight  operations  tasks  and  services  directly  related 
to  the  post^aunch  real-time  operational  control  of  the  Space  Tug  and  IUS 
vehicles  These  activities  include  mission  planning  and  Documentation, 
Operational  preparations.  Flight  Readiness  Testing  and  Real-Time  Flight 
Control 

320-10-01  MISSION  PLANNING  AND  DOCUMENTATION 

This  task  includes  efforts  to  develop  and  document  mission  rules  and  flight 
control  procedures,  analyze  mission  effects  of  system  malfunction,  analyse 
vehicle  component  characteristics,  preparation  and  update  of  reference 
documents,  documentation  of  requirements  on  and  procedures  for  testing 
support  network  interface 


Table  10.3.0-2  MBS  Definitions  (Continued) 


320-10-01-01  DEVELOP  TUG  PROCEDURES  AND  RULES 

The  specific  rules  and  procedures  utilized  during  the  mission  will  consist 
of  a fundamental  set  of  procedures  and  rules  which  are  applicable  across  all 
Tug  missions,  and  a mission  specific  set  of  rules  and  procedures.  The  output 
of  this  task  is  a document  containing  all  predefined  mission  decisions,  a 
document  containing  basic  step-by-step  implementation  procedures,  a set  of 
predefined  contingency  procedures  and  a vehicle  command  listing 

XXX-10-01-01  DEVELOP  IUS  PROCEDURES  AND  RULES 

The  specific  rules  and  procedures  utilized  during  the  mission  will  consist  of 
a fundamental  set  of  procedures  and  rules  which  are  applicable  across  all 
IUS  missions,  and  a mission  specific  set  of  rules  and  procedures.  The  output 
of  this  task  is  a document  containing  all  predefined  mission  decisions,  a 
document  containing  basic  step-by-step  implementation  procecures,  a set  of 
predefined  contingency  procedures  and  a vehicle  command  listing 

XXX-10-01-02  IUS  MISSION  FAILURE  EFFECTS  ANALYSIS 

Once  the  IUS  failure  modes  have  been  identified  and  categorized,  the  occur- 
rence of  these  failures  at  various  points  in  the  flight  must  be  evaluated 
for  overall  mission  effect  The  output  of  this  task  will  be  a senes  of 
scenarios  against  which  pre-thought  decisions  may  be  constructed 

320-10-01-02  TUG  MISSION  FAILURE  EFFECTS  ANALYSIS 

Once  the  Space  Tug  failure  modes  have  been  identified  and  categorized,  the 
occurrence  of  these  failures  at  various  points  in  the  flight  must  be  evaluated 
for  overall  mission  effect  The  output  of  this  task  will  be  a series  of 
scenarios  against  which  pre-thought  decisions  may  be  constructed. 

320-10-01-03  ANALYZE  TUG  COMPONENT  CHARACTERISTICS 

This  task  includes  all  efforts  required  to  assemble  basic  operational 
information  describing  the  characteristics  of  the  operationally  significant 
components  of  the  Tug  vehicle  The  output  of  this  task  is  a compendium  of 
nominal  operational  performance,  characteristic  performance  curves,  expec- 
tations of  behavior,  etc  This  output  will  be  utilized  in  the  preparation  of 
training  material  and  a reference  handbooi 

XXX-10-01-03  ANALYZE  IUS  COMPONENT  CHARACTERISTICS 

This  task  includes  all  efforts  required  to  assemble  basic  operational 
information  describing  the  characteristics  of  the  operationally  significant 
components  of  the  IUS  vehicles.  The  output  of  this  task  is  a compendium  of 
nominal  operational  performance,  characteristic  performance  curves,  expecta- 
tions of  behavior,  etc  This  output  will  be  utilized  in  the  preparation  of 
training  material  and  a reference  handbook 

320-10-01-04  FLIGHT  CONTROL  SYSTEMS  HANDBOOK 

This  task  includes  the  acquisition,  assembly  and  preparation  of  Space  Tug 
or  IUS  vehicle  systems  data  in  a form  which  is  readily  accessible  to 
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real-time  operational  personnel  This  incudes  schematic  diagrams, 
performance  characteristics,  component  characteristics  and  inherent  con- 
straints and  limitations  on  vehicle  operations 

320-10-01-04-01  PREPARE  TUG  SYSTEM  HANDBOOK 

This  task  includes  all  efforts  required  to  generate  simplified  schematic 
diagrams,  simplified  interface  connections,  a summary  of  component 
characteristics,  prediction  of  mission  events  and  performance  curves,  and 
inherent  Space  Tug  constraints  and  limitations 

XXX-10-01-04-01  PREPARE  IUS  SYSTEM  HANDBOOK 

This  task  includes  all  efforts  required  to  generate  simplified  schematic 
diagrams,  simplified  interface  connections,  a summary  of  component 
characteristics,  prediction  of  mission  events  and  performance  curves,  and 
inherent  IUS  constraints  and  limitations 

320-10-01-04-02  PUBLISH  AND  UPDATE  SPACE  TUG  SYSTEM  HANDBOOK 

The  basic  publication  of  a Space  Tug  system  handbook  will  incorporate  the 
information  prepared  for  that  purpose  under  one  cover  The  updating  of  a 
system  handbook  will  be  on  a by-mission,  and  as  required,  basis,  and  thus, 

is  an  iterative  task  Major  updates  and  changes  to  the  Space  Tug  baseline 

design  must  be  incorporated  into  the  systems  handbook  prior  to  the  utili- 
zation of  that  vehicle  for  a mission. 

XXX-10-01-04-02  PUBLISH  AND  UPDATE  IUS  SYSTEM  HANDBOOK 

The  basic  publication  of  a Space  Tug  system  handbook  will  incorporate  the 
information  prepared  for  that  purpose  under  one  cover  The  updating  of  a 
system  handbook  will  be  on  a by-mission,  and  as  required,  basis,  and  ^hus, 

is  an  iterative  task.  Major  updates  and  changes  to  the  IUS  baseline 

design  must  be  incorporated  into  the  systems  handbook  prior  to  the  utilization 
of  that  vehicle  for  a mission 

320-10-01-05  NETWORK  INTERFACE  DOCUMENTATION 

This  element  includes  efforts  required  to  establish  performance  requirements 
on  the  data  network  feeding  the  Flight  Operations  control  center,  and  to 
generate  proof-of-performance  test  procedures  for  the  network 

XXX-10-01-05-01  DEFINE  GROUND  NETWORK  TRACKING  REQUIREMENTS 

This  task  includes  those  systems  analyses,  mission  engineering,  flight 
control  and  flight  support  efforts  required  to  develop  a checkout  procedure 
which  will  exercise  the  tracking  capabilities  of  the  support  network  from 
the  flight  control  and  flight  support  consoles  in  the  Mission  Control  Center 
The  output  of  this  task  will  be  a procedural  c'.ecklist  which  will  be  followed 
in  the  actual  testing  of  the  network  proof-of-performance. 
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XXX-10-01-05-02  NETWORK  TRACKING  VALIDATION  PROCEDURES 

This  task  includes  those  systems  analyses,  mission  engineering,  flight  con- 
trol and  flight  support  efforts  required  to  develop  a checkout  procedure 
which  will  exercise  the  tracking  capabilities  of  the  support  network  from 
the  flight  control  and  flight  support  consoles  in  the  Mission  Control  Center 
The  output  of  this  task  will  be  a procedural  checklist  which  will  be  followed 
in  the  actual  testing  of  the  network  proof-of-performance 

320-10-01-05-03  SPACE  TUG  NETWORK  DATA  HANDLING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  produce  a document  levying  specific 
data  handling,  processing,  and  special  requirements  on  the  supporting  network 
This  includes  both  updata  and  downdata  processing 

XXX-10-01-05-03  IUS  NETWORK  DATA  HANDLING  REQUIREMENTS 

This  task  includes  all  efforts  required  to  produce  a document  levying  specific 
data  handling,  processing,  and  special  requirements  on  the  supporting  network 
This  includes  both  updata  and  downdata  processing 

320-10-01-05-04  TUG  NETWORK  DATA  VALIDATION  PROCEDURES 

This  task  includes  all  efforts  required  to  establish  proof-of-performance 
criteria  for  the  acceptance  test  of  Tug-peculiar  ground  software. 

XXX-10-01-05-04  IUS  NETWORK  DATA  VALIDATION  PROCEDURES 

This  task  includes  all  efforts  required  to  establish  proof-of-performance 
criteria  for  the  acceptance  test  of  IUS-peculiar  ground  software. 

320-10-02  OPERATIONAL  PREPARATIONS 

This  element  includes  efforts  to  establish  the  interface  with  the  data  ac- 
quisition network,  to  design  the  basic  layout  of  flight  control  consoles 
and  flight  support  consoles,  and  to  establish  the  display  format,  engineering 
units  and  special  processing  requirements  for  data  display  to  flight  control 
and  flight  support  personnel 

320-10-02-01  DESIGN  NETWORK  INTERFACE 

This  tasK  includes  the  engineering  effort  necessary  to  establish  the  interface 
with  the  data  acquisition  network.  It  specifically  includes  telemetry 
decommutation  and  special  processing,  command  processing,  television,  and 
tracking  format  and  processing  requirements.  The  output  of  this  task  will 
be  the  operational  requirements  for  a network  interface  system  design  which 
will  include  suggested  hardware  items 

320-10-02-02  CONSOLE  ORGANIZATION 

This  task  includes  all  efforts  necessary  to  establish  the  requirements  for 
location  of  console  display  and  control  devices  to  the  satisfaction  of  the 
console  operating  personnel 
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320-10-02-03  TUG  DISPLAY  FORMAT  DESIGN 

This  task  includes  all  efforts  required  to  establish  the  organizational, 
display  format  and  engineering  units  for  flight  control  and  flight  support 
personnel  digital  TV  presentation  This  task  also  includes  all  efforts 
directed  toward  the  definition  of  the  special  processing  requirements, 
remote  site  and  control  center  logical  operations,  limit  sensing,  event  light 
triggering,  etc 

XXX-10-02-03  IUS  DISPLAY  FORMAT  DESIGN 

This  task  includes  all  efforts  required  to  establish  the  organization,  display 
format  and  engineering  units  for  flight  control  and  flight  support  personnel 
digital  TV  presentation  This  task  also  includes  all  efforts  directed  toward 
the  definition  of  the  special  processing  requirements,  remote  site  and  control 
center  logical  operations,  limit  sensing,  event  light  triggering,  etc 

320-10-03  MISSION  READINESS  TESTING 

This  element  includes  all  efforts  required  to  set-up  and  conduct  pre-mission 
proof-of-performance  tests  on  the  flow  of  data  into  the  control  center  from 
the  ground  site(s)  of  the  data  acquisition  network 

XXX-10-03-01  NETWORK  TRACKING  VALIDATION  TESTS 

This  task  includes  all  efforts  required  to  set  up  and  conduct  specific  pre- 
mission tests  of  the  tracking  capabilities  and  tracking  accuracies  of  the 
support  network  This  will  involve  the  generation  of  tapes  to  simulate 
over-flying  vehicles  and  ground  receiving  tracking  stations,  the  distribution 
and  execution  of  procedures  previously  prepared  and  the  evaluation  of  test 
results 

320-10-03-02  SPACE  TUG  NETWORK  VALIDATION  TESTS 

This  task  includes  all  efforts  required  to  conduct  tests  of  the  network 
handling  of  Space  Tug  peculiar  software,  including  the  providing  of  vehicle 
simulation  tapes  to  remote  sites  of  tne  ground  data  acquisition  network, 
providing  the  procedures  to  remote  operations,  and  providing  personnel  to 
conduct  these  tests, 

XXX-10-03-02  IUS  NETWORK  VALIDATION  TESTS 

This  task  includes  all  efforts  required  to  conduct  tests  of  the  network 
handling  of  lUS-peculiar  software,  including  the  providing  of  vehicle 
simulation  tapes  to  remote  sites  of  the  ground  data  acquisition  network, 
providing  the  procedures  to  remote  operators,  and  providing  personnel  to 
conduct  these  tests 

320-10-04  CONDUCi  SPACE  TUG  MISSION  OPERATIONS 

This  task  includes  all  efforts  necessary  to  provide  control  and  support  to 
the  Space  Tug  vehicle  in  prelaunch,  orbital  operations,  placement,  retrieval 
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and  landing  phases.  This  task  requires  the  total  attention  of  the  flight 
control  team,  the  flight  support  team,  and  other  personnel  This  task  is 
the  culmination  of  all  prior  efforts. 

XXX-10-04  CONDUCT  IUS  MISSION  OPERATIONS 

This  task  includes  all  efforts  necessary  to  provide  control  and  support  to  the 
IUS  vehicle  in  prelaunch,  orbital  operations  and  placement  mission  phases. 

This  task  requires  the  total  attention  of  the  flight  control  team,  the 
flight  support  team,  and  other  personnel  This  task  is  the  culmination  of 
all  prior  efforts 

320-15  SOFTWARE 

This  element  summarizes  all  tasks  and  services  required  to  analyze,  develop, 
verify  and  implement  Tug  and  IUS  software  It  includes  design,  processing 
and  implementation  of  software  (computer  languages,  computer  programs,  pro- 
gram verification,  debugging,  etc.)  for  ground  and  airborne  subsystems. 

320-15-01  FLIGHT  SOFTWARE 

This  element  consists  of  task  and  services  required  to  analyze,  design, 
develop,  simulate,  verify  and  maintain  software  for  use  onboard  the  IUS  or 
Tug  to  support  IUS  and  Tug  requirements 

320-15-01-01  PLAN  FLIGHT  SOFTWARE  DEVELOPMENT 

This  task  includes  all  efforts  required  to  establish  a schedule  for  develop- 
ment of  the  flight  software,  establish  design  concept  validation  procedures, 
establish  the  necessity  for,  and  required  characteristics  of,  hybrid  and 
interpretive  simulators,  establishing  a plan  for  the  integration  of  the  IUS 
and  Space  Tug  flight  software  development  to  minimize  cost,  and  establishing 
controls  and  feedback  to  insure  customer  requirements  on  the  IUS  and  Space 
Tug  flight  software  are  fulfilled 

320-15-01-02  BASELINE  FLIGHT  PROGRAM  DEVELOPMENT 

This  element  includes  the  creation  of  an  Equation  Defining  Document  (EDD), 
programming  and  verification  of  four  basic  flight  programs  for  the  IUS  and 
four  basic  flight  programs  for  the  Space  Tug 

320-15-01-02-01  EQUATION  DEFINING  DOCUMENT  - SPACE  TUG  FLIGHT  PROGRAM 

This  task  includes  basic  conceptual  work  on  the  requirements  for  flight 
software,  customer  support  and  flight  software  definition,  definitions  of 
equations  pertaining  to  vehicle  dynamics,  design  of  algorithm  techniques 
and  the  associated  simulation  equipments,  the  generation  of  a program  require- 
ments document  known  as  the  Equation  Defining  Document  (EDD),  control  of 
requirements,  performance  of  software  implementation  studies,  analysis  of 
sample  calculations,  definition  of  flight  control  functional  interfaces, 
definition  of  hardware  interfaces,  and  miscellaneous  preliminary  analysis. 
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XXX-15-01-02-01  EQUATION  DEFINING  DOCUMENT  - IUS  FLIGHT  PROGRAM 

This  task  includes  basic  conceptual  work  on  the  requirements  for  flight 
software,  customer  support  and  flight  software  definition,  definitions  of 
equations  pertaining  to  vehicle  dynamics,  a design  of  algorithm  techniques 
and  the  associated  simulation  equipments,  the  generation  of  a program  require- 
ments document  known  as  the  Equation  Defining  Document  (EDD),  control  of 
requirements,  performance  of  software  implementation  studies,  analysis  of 
sample  calculations,  definition  of  flight  control  functional  interfaces, 
definition  of  hardware  interfaces,  and  miscellaneous  preliminary  analysis 

320-15-01-02-02  PROGRAM  TUG  FLIGHT  SOFTWARE 

This  task  includes  all  efforts  required  to  develop  preflight  and  flight 
software  to  satisfy  baseline  requirements  Included  are  performance  of 
overall  softv/are  system  design  based  on  execution  rates,  input/output  require- 
ments, and  response  time  restrictions,  design  and  develop  documentation, 
participate  in  design  reviews,  perform  systematic  integration  testing  of 
softv/are,  update  software  as  a result  of  change  activity,  participate  in 
configuration  control,  and  perform  program  delivery  generation  and  validation 

XXX-15-01-02-02  PROGRAM  IUS  FLIGHT  SOFTWARE 

This  task  includes  all  efforts  required  to  develop  preflight  and  flight 
software  to  satisfy  baseline  requirements  Included  are  performance  of 
overall  software  system  design  based  on  execution  rates,  input/output  require- 
ments, and  response  time  restrictions;  design  and  develop  executive  and 
application  program  modules,  generate  detailed  software  design  documentation, 
participate  in  design  reviews,  perform  systematic  integration  testings  of 
software,  update  software  as  a result  of  change  activity,  participate  in 
configuration  control,  and  perform  program  delivery  generation  and  validation 

320-15-01-02-03  SPACE  TUG  FLIGHT  PROGRAM  VERIFICATION 

The  objective  of  program  verification  is  to  insure,  thru  systematic  testing 
by  a independent  functional  area,  that  the  flight  software  satisfies  all 
requirements  levied  on  it  by  the  Equation  Defining  Document  To  accomplish 
this  objective,  the  following  activities  are  performed  analysis  of  software 
reqirements,  generation  of  a detailed  testing  plan,  performance  of  systematic 
tests,  analysis  of  software  listings,  comparison  of  flight  softv/are  derived 
results  with  independently  generated  results,  analysis  of  hardware/ software 
compatabi  1 1 ty , reverifi cation  of  all  changes  made  to  the  software  <-nd  generation 
of  documented  test  results. 

XXX- 15-01-02-03  IUS  FLIGHT  PROGRAM  VERIFICATION 

- 

The  objective  of  program  verification  is  to  insure,  thru  systematic  testing 
by  an  independent  functional  area,  that  the  flight  software  satisfies  all 
requirements  levied  on  it  by  the  Equation  Defi  ing  Document  To  accomplish 
this  objective,  the  following  activities  are  performed  analysis  of  software 
requirements,  generation  of  a detailed  testing  plan,  performance  of  systematic 
tests,  analysis  of  software  listings,  comparison  of  flight  software  derived 
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results  with  independently  generated  results,  analysis  of  hardware/software 
compatibility,  revenfi cation  of  all  changes  made  to  the  software  and  genera- 
tion of  documented  test  results. 

320-15-01-03  MISSION  SPECIFIC  PROGRAM  MODIFICATION 

This  element  includes  all  efforts  required  to  modify  the  baseline  flight 
programs  to  perform  specific  IUS  or  Space  Tug  missions  This  includes 
the  EDD,  programming  and  verification  of  mission  specific  "application 
modules". 

320-15-01-03-01  TUG  MISSION  SPECIFIC  EQUATION  DEFINING  DOCUMENT  (EDD) 

This  task  includes  all  efforts  required  to  modify  the  definition  of  the  base- 
line Space  Tug  flight  program  to  incorporate  mission  specific  peculiarities. 
This  task  is  iterative  and  must  be  repeated  prior  to  each  flight 

XXX-15-01-03-01  IUS  MISSION  SPECIFIC  EQUATION  DEFINING  DOCUMENT  (EDD) 

This  task  includes  all  efforts  required  to  modify  the  definition  of  the 
baseline  IUS  flight  program  to  incorporate  mission  specific  pecularities 
This  task  is  iterative  and  must  be  repeated  prior  to  each  flight 

320-15-01-03-02  TUG  MISSION  SPECIFIC  PROGRAMMING 

This  task  develops  the  "application  module"  which  incorporates  the  specific 
deviations  from  the  baseline  program  required  by  the  subject  Space  Tug 
mission  This  task  is  iterative  and  must  be  repeated  prior  to  each  flight. 

XXX-15-01-03-02  IUS  MISSION  SPECIFIC  PROGRAMMING 

This  task  develops  the  "application  Module"  which  incorporates  specific 
deviations  from  the  baseline  program  required  by  the  subject  IUS  mission. 

This  task  is  iterative  and  must  be  repeated  prior  to  each  flight 

320-15-01-03-03  TUG  MISSION  PROGRAM  VERIFICATION 

This  task  includes  efforts  necessary  to  analyze  flight  program  implementation 
of  the  Equation  Defining  Document  for  this  "application  module"  The  task 
includes  generation  of  a detailed  testing  plan  to  insure  that  all  require- 
ments are  satisfied,  the  performance  of  systematic  tests,  and  generation  of 
a test  results  document 

XXX-15-01-03-03  IUS  MISSION  PROGRAM  VERIFICATION 

This  task  includes  efforts  necessary  to  analyze  flight  program  implementation 
of  the  Equation  Defining  Document  for  this  "application  module"  The  task 
includes  generation  of  a detailed  testing  plan  to  insure  that  all  require- 
ments are  satisfied,  the  performance  of  systematic  tests,  and  generation  of 
a test  results  document 
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320-15-02  GROUND  SOFTWARE 

This  element  consists  of  tasks  and  services  required  to  analyze,  design, 
develop,  simulate,  verify  and  maintain  software  used  in  the  lUS/Space  Tug 
Mission  control  center 

320-15-02-01  PLAN  GROUND  SOFTWARE  DEVELOPMENT 

This  task  includes  all  efforts  necessary  to  establish  a plan  for  the  develop- 
ment of  IUS  and  Space  Tug  ground  software  Included  will  be  the  advisability 
of  transforming  softv/are  modules  from  existing  ground  control  systems, 
establishment  of  the  basic  data  processing  techniques,  planning  the  use  of 
existing  ground  system  simulators,  and  establishing  ground  program  organiza- 
tion and  source  strings,  and  establishing  a maximum  transfer  capability 
between  IUS  and  Space  Tug  ground  support  software 

320-15-02-02  EQUATION  DEFINITION 

This  element  consists  of  all  efforts  in  equation  definition  and  algorithm 
development  for  Space  Tug  and  IUS  ground  programs 

320-15-02-02-01  EQUATION  DEFINING  DOCUMENT  - EXECUTIVE/TRACKING/ 

PLANNING  SOFTWARE 

This  task  includes  those  efforts  from  the  definition  and  analysis  to  the 
development  of  the  equations  and  algorithms  to  be  utilized  in  the  Space 
Tug  and  IUS  ground  programs  It  is  limited  to  those  equations  and  algorithms 
which  will  not  change  during  transition  from  IUS  operations  to  Space  Tug 
operations,  with  the  exception  of  the  lUS-peculiar  tracking  requirements, 
which  will  be  phased  out  when  the  IUS  becomes  non-operational 

320-15-02-02-02  TUG  DOWN  DATA/UP  DATA  AND  DOCKING  GROUND  SOFTWARE 

This  task  includes  all  efforts  required  to  create  an  Equation  Defining 
Document  (EDD)  for  those  ground  software  modules  which  are  specifically 
oriented  to  the  Space  Tug  The  output  of  this  task  is  an  Equation  Defining 
Document  against  which  the  ground  Tug-peculiar  software  will  be  programmed 

XXX-15-02-02-02  IUS  DOWN  DATA/UP  DATA  AND  SIMULATION  GROUND  SOFTWARE 

This  task  includes  all  efforts  required  to  ci  aate  an  Equation  Defining 
Document  (EDD)  for  those  ground  software  modules  which  are  specifically 
oriented  to  the  IUS.  The  output  of  this  task  is  an  Equation  Defining  Doc- 
ument against  which  the  ground  IUS-peculiar  software  will  be  programmed 

320-15-02-03  PROGRAMMING 

This  element  includes  the  coding  of  all  equations  and  algorithms  specified 
for  the  IUS  and  Space  Tug  Ground  programs 

320-15-02-03-01  PROGRAM  GROUND  TRACKING,  PLANNING  AND  EXECUTIVE  ROUTINES 

This  task  depends  on  the  generation  of  an  adequate  Equation  Defining  Document 
at  a prior  time,  and  includes  the  programming  of  all  fundamental  routines 
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320-15-02-03-02  PROGRAM  SPACE  TUG  DOWN  DATA/UP  DATA  AND  SIMULATION  SYSTEM 

This  task  includes  all  efforts  required  to  design  an  overall  software  system 
based  on  execution  rates,  input/output  requirements,  and  response  restric- 
tions, design  and  develop  Tug  specific  program  modules,  generating  a detailed 
software  design  document,  participation  in  design  reviews,  perform  software 
integration  testing,  participate  m change  reviews  and  update  software, 
provide  configuration  control  and  perform  program  generation,  delivery  and 
validation 

XXX-15-02-03-02  PROGRAM  IUS  DOWN  DATA,  UP  DATA  AND  SIMULATION  SYSTEM 

This  task  includes  all  efforts  required  to  design  an  overall  software  system 
based  on  execution  rates,  mput/output  requirements,  and  response  restric- 
tions, design  and  develop  IUS  specific  program  modules,  generating  a detailed 
software  design  document,  participation  m design  reviews,  perform  software 
integration  testing,  participate  in  change  reviews  and  update  software, 
provide  configuration  control  and  perform  program  generation,  delivery  and 
validation 

320-15-02-04  PROGRAM  VERIFICATION 

This  task  includes  all  activities  required  to  insure,  through  systematic 
testing  by  an  independent  functional  area,  that  the  ground  software  developed 
meets  the  intent  of  the  Equation  Defining  Documents 

320-15-02-04-01  VERIFY  EXECUTIVE  TRACKING  AND  PLANNING  SOFTWARE 

This  task  verifies  that  the  intent  of  the  Equation  Defining  Document  has 
been  implemented  in  the  developed  programs  by  testing  the  coded  program 
under  critical  operational  situations  and  includes  the  development  of  any 
special  tools  or  simulators  necessary  m the  accomplishment  of  this  task. 

320-15-02-04-02  VERIFY  TUG  DOWN  DATA/UP  DATA  AND  SIMULATION  PROGRAMMING 

This  task  includes  all  activities  involved  to  insure,  thru  systematic  testing 
by  an  independent  functional  area,  that  the  Tug  peculiar  ground  software 
satisfies  all  requirements  levied  upon  it  by  the  Equation  Defining  Document 
This  includes  analysis  of  software  requirements  to  insure  accuracy,  adequacy, 
and  completeness,  generation  of  a detailed  testing  plan,  performance  of 
systematic  tests  utilizing  interpretive  simulators,  analysis  of  software 
listings,  analysis  of  hardware/software  compatibility  and  validation  of  all 
changes  made  to  the  basic  software  package 

XXX-15-02-04-02  VERIFY  IUS  DOWN  DATA/UP  DATA  AND  SIMULATION  PROGRAMMING 

This  task  includes  all  activities  involved  to  insure,  thru  systematic  testing 
by  an  independent  functional  area,  that  the  IUS-peculiar  ground  software 
satifies  all  requirements  levied  upon  it  by  the  Equation  Defining  Document. 
This  includes  analysis  of  software  requirements  to  insure  accuracy,  adequacy, 
and  completeness,  generation  of  a detailed  testing  plan,  performance  of 
systematic  tests  utilizing  interpretive  simulators,  analysis  of  software 
listings,  analysis  of  hardware/software  compatibility  and  validation  of  all 
changes  made  to  the  basic  software  package 
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320-15-02-05  MISSION  SPECIFIC  SIMULATION 

This  element  includes  all  efforts  in  equation  definition,  programming  and 
verification  required  to  incorporate  specific  mission  profiles  and  contingency 
cases  into  the  basic  IUS  or  Space  Tug  simulation. 

320-15-02-05-01  PROGRAM  TUG  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  modify  the  baseline  Tug  simulator 
to  incorporate  mission  specific  profiles  and  contingency  cases  This  task 
accepts  as  inputs  the  output  from  the  Space  Tug  mission  planning  and  optimi- 
zation task,  and  the  Space  Tug  abort  planning  task,  as  well  as  outputs  from 
Space  Tug  basic  simulation  design  This  task  is  iterative  and  must  be 
repeated  for  each  flight  This  task  is,  in  a sense,  a mission  specific 
simulation  application  module. 

XXX-15-02-05-01  PROGRAM  IUS  MISSION  SIMULATION 

This  task  includes  all  efforts  required  to  modify  the  baseline  IUS  simulator 
to  incorporate  mission  specific  profiles  and  contingency  cases  This  task 
accepts  as  inputs  the  output  from  the  IUS  mission  planning  and  optimization 
task,  and  the  IUS  abort  planning  task,  as  well  as  outputs  from  IUS  basic 
simulation  design  This  task  is  iterative  and  must  be  repeated  for  each 
flight  This  task  is  m a sense  a mission  simulation  application  module 

320-15-02-06  GROUND  SOFTWARE  MAINTENANCE 

This  element  includes  efforts  required  to  maintain  the  ground  software  in 
operable  condition  and  to  incorporate  modification  and  enhancements  to  the 
ground  programs  This  is  a level  of  effort  task 

320-15-03  COMPUTER  SELECTION  SUPPORT 

This  element  includes  all  analytical  tasks  involved  in  the  selection  of  the 
optimum  operational  data  system  for  the  IUS/Space  Tug  Control  Center 

320-15-03-01  ESTIMATE  GROUND  SOFTWARE  SIZE 

This  task  analyzes  the  Equation  Defining  Document  for  ground  software  and 
establishes  a lower  boundary  upon  the  data  system  memory  size  and  central 
processor  unit  speed  requirements  For  maximum  cost-effectiveness  this  task 
should  be  completed  prior  to  the  selection  ot  an  operational  data  system 
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1(M  I US/SPACE  TUG  PHASEOVER  CONSTRAINTS 

This  section  evaluates  the  current  planning  of  IUS  and  Space  Tug  traffic, 
then  schedules  the  earliest  and  latest  times  to  effect  transition  on  an 
element  by  element  basis. 

10  4 1 Observations  From  the  Space  Transportation  System  Traffic  Model 

The  space  transportation  system  traffic  model  is  imprecisely  defined  at 
this  time.  The  best  available  information  indicates  that  the  first  NASA 
IUS  flight  will  take  place  in  April,  1981. 

The  information  developed  in  this  section  is  based  upon  the  following  basic 
assumptions 

1.  NASA  and  DoD  will  not  share  a common  facility  or  operational 
interface. 

2 The  IUS  will  be  Expendable  at  level  B autonomy 

3.  The  IUS  will  have  a digital  command  system  similar  to  the 
Space  Tug  command  system. 

4.  The  Space  Tug  configuration  will  be  at  Level  II  autonomy. 

5.  Communications  equipment  will  have  similar  external 
characteristics  for  both  the  IUS  and  Space  Tug. 

6.  Telemetry  and  command  format  will  have  maximum  similarity  for  IUS 
and  Space  Tug  configurations. 

The  Tug  Fleet  and  Ground  Operations  Schedules  and  Controls  Study,  Second 
Performance  Review  Report,  (Martin  Marietta  Corporation  report  MCR-74-487, 
December  10  -12,  1974)  offers  three  options  for  expendable  IUS  utilization. 
Option  one  presumes  immediate  phasing  between  IUS  and  Space  Tug  with  no 
transition.  The  last  IUS  flight  to  occur  in  1983,  and  the  first  Tug  flight 
to  occur  in  early  1984.  The  second  model  presumes  a transition  through 
the  year  1984  during  which  time  both  IUS  and  Space  Tug  missions  will  be 
flown  The  third  option  takes  advantage  of  the  expendable  nature  of  the 
IUS  to  substitute  for  Space  Tug  carrier  vehicles  on  missions  where  the 
carrier  vehicle  must  be  expended. 

Preliminary  planning  thus  indicates,  in  the  later  two  cases,  that  the 
ability  to  simultaneously  control  the  Space  Tug  and  the  IUS  is  a program 
requirement.  To  accommodate  any  overlap,  it  is  obvious  that  maximum 
commonality  of  ground  equipment  must  be  a program  objective.  The 
composite  IUS/SPACE  TUG  Work  Breakdown  Structure  and  Dictionary  presented 

in  Section  10.3  of  this  reoort  has  presumed  maximum  commonality  of  eauioment 
performing  similar  functions.  The  telemetry  and  command  systems  are  more 
vulnerable  to  impact  by  vehicle  individual  peculiarities,  and  will  thus  be 
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carried  as  separate  line  items  in  the  development  plan  It  will  be 
presumed  that  there  will  be  no  additional  personnel  requirements 
resulting  from  the  overlap  of  IUS  and  Space  Tug  missions 

10.4  2 Common  Elements  Development  Plan 

Table  10  4 2-1  lists  the  elements  common  to  both  the  IUS  and  Space  Tug 
programs  These  elements  fall  into  the  following  general  areas 

1.  Program  planning  and  schedule  analysis 

2 Console  hardware  design  requirements  and  selection 

3 Network  interface  design  requirements  and  equipment 
selection 

4.  Operational  data  system 

5.  Physical  Plant 

6 Ground  software  in  the  areas  of  operating  system  (the 
executive)  and  mission  planning 

Some  of  the  tasks  listed  in  Table  10  4.2-1  are  constrained  by  the  completion 
of  tasks  which  are  unique  to  either  the  IUS  and  Space  Tug  program.  Section 
10-6  will  present  an  integrated  program  development  plan  in  which  the 
constraining  relationships  are  discussed 

10  4.3  Modifiable  Elements  Development  and  Phasing  Plan 

Table  10.4  3-1  presents  the  elements  modifiable  for  IUS  to  Space  Tug  utili- 
zation Those  elements  are  the  maintenance  schedule,  the  network  interface 
design,  the  display  format  design,  and  the  console  position  guidelines 

The  maintenance  schedule  will  include  all  periodic  contracted  and  schedulable 
maintenance  activities  throughout  the  IUS  Space  Tug  era.  The  maintenance 
plan  is  dependent  upon  a number  of  factors,  one  of  these  factors  is  the 
kind  and  type  of  equipment  to  be  maintained.  The  Space  Tug  will  bring 
additional  hardware  online  to  support  television  monitored  rendezvous  and 
docking  acitivites.  The  addition  of  Space  Tug  peculiar  equipment  will 
force  a modification  of  the  baseline  maintenance  schedule  planning 

Similarly,  the  Space  Tug  program  will  bring  additional  equipment  items  into 
the  network  interface,  particularly  television  related  items.  Additionally, 
it  is  expected  that  there  will  be  some  deviation  in  telemetry  format  and 
command  uplink  requirements  and  format  as  the  Space  Tug  control  system  is 
brought  on  line  The  initial  selection  of  equipment  should  be  sufficiently 
flexible  to  encompass  both  IUS  and  Space  Tug  network  interface  constraints, 
however,  some  modification  of  the  network  interface  should  be  expected 
during  the  transition  period  when  Space  Tug  is  becoming  the  dominant 
program. 
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Table  10  42 1.  Elements  Common  to  I US  and  Space  Tug' 


MASTER  LAUNCH  SCHEDULE  ANALYSIS 
CONTRACT  SOFTWARE  DEVELOPMENT 
PLAN  FACILITY  UTILIZATION 
PLAN  FLIGHT  SOFTWARE  DEVELOPMENT 
PLAN  GROUND  SOFTWARE  DEVELOPMENT 
MISSION  PHASE  MANNING  REQUIREMENTS 
COMPUTER  UTILIZATION  PLAN 
MAINTENANCE  SCHEDULE 
HIRE  CONTROL  AND  SUPPORT  STAFF 
CONSOLE  ORGANIZATION 
DESIGN  NETWORK  INTERFACE  SYSTEM 
ESTIMATE  GROUND  SOFTWARE  SIZE 
SELECT  OPERATIONAL  DATA  SYSTEM 
INSTALL  OPERATIONAL  DATA  SYSTEM 
SIZE  FACILITY/ DESIGN  PHYSICAL  PLANT 
CONSTRUCT  PHYSICAL  PLANT 
INSTALL  OPERATIONAL  CONSOLES/HARDWARE 
EDD-EXECUTIVE/TRACKING/PLANNING 
COMMON  GND  SW  VALID  TEST  REQUIREMENTS 
PROGRAM  GROUND  TK/PLAN/EX  SOFTWARE 
VERIFY  EXECUTIVE/TK/PLAN  SOFTWARE 


Table  10.4  3-1  Elements  Modifiable  from  I US  to  Space  Tug 


MAINTENANCE  SCHEDULE 
DESIGN  NETWORK  INTERFACE 
DISPLAY  FORMAT  DESIGN 
CONSOLE  POSITION  GUIDELINES 
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Display  format  design  is  a function  of  the  vehicle  systems  configuration, 
parameters  downlinked,  and  command  uplink  requirements  (except  in  the  area 
of  flight  dynamics).  In  the  flight  dynamics  area  the  disparity  of  trajectory 
expectations  between  the  IUS  expendable  missions  and  the  Space  Tug  recover- 
able missions  will  require  an  update  and  modification  of  the  flight  dynamics 
related  console  displays 

Console  positions  guidelines  define  the  operational  relationships  and 
organizational  hierarchy  which  implements  the  control  philosophy  for  a 
particular  program  This  task  will  be  executed  once  for  the  IUS  program 
and  then  modified  for  Space  Tug  implementation  based  upon  experience 
gained  during  the  IUS  program.  It  has  been  observed  that,  historically, 
duties  and  responsibilities  of  a particular  console  position  are  re- 
allocated as  the  program  matures  The  integrated  IUS/SPACE  TUG  program 
allows  an  opportunity  for  planning  the  modification  of  console  position 
guidelines  at  a convenient  time  in  the  transition  between  programs. 

10  4 4 IUS  Elements  Development  Plan 

Table  10  4 4-1  presents  the  elements  unique  to  the  IUS  program  The  ele- 
ments fall  into  eight  broad  categories,  mission  design,  flight  program  design, 
development  and  verification,  IUS  peculiar  training  and  training  criteria, 
network  IUS  data  handling  requirements,  ground  programs  in  the  IUS  specific 
areas  of  tracking,  down  data,  up  data,  and  simulation  interagency 
relationships,  as  related  to  other  NASA  centers  and  the  DoD,  IUS  mission 
specific  elements,  and  IUS  post-mission  reports 

The  IUS  peculiar  elements  and  the  common  elements  must  be  completed  before 
the  first  IUS  launch  (with  the  exception  of  IUS  post-mission  reports). 

The  overall  development  plan  presented  in  Section  10-6  will  illustrate  that, 
to  meet  an  April  1981  launch  of  an  Interim  Upper  Stage,  the  development  of 
the  common  and  IUS  peculiar  operational  elements  must  start  no  later  than 
January,  1977 

10  4 5 Space  Tug  Unique  Elements  Development  Plan 

Table  10  4 5-1  present  the  Space  Tug  unique  operational  elements.  These 
fall  into  the  general  categories  of  mission  design,  flight  program  design, 
development  and  verification,  Space  Tug  training  and  training  criteria. 

Space  Tug  peculiar  network  data  handling  requirements,  ground  programs  in 
the  areas  of  down  data  processing,  up  data  processing,  docking  support. 

Space  Tug  simulation,  interagency  relationships.  Space  Tug  mission 
specific  elements,  and  Space  Tug  mission  reports. 

The  transition  plan  presented  in  Section  10,6  shows  that  in  order  to  meet 
a fourth  quarter  1983  launch  with  the  Space  Tug  it  is  necessary  to  begin 
the  Space  Tug  peculiar  operational  element  development  no  later  than 
February  1982.  This  is  presuming  that  the  tasks  which  are  common  to 
the  IUS  and  Space  Tug  have  been  completed  in  support  of  the  IUS  program 
It  should  be  noted  that  IUS  operations  will  be  continuing  during  the  time 
that  the  Space  Tug  peculiar  program  development  tasks  are  being  performed. 
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Table  10441  Elements  Unique  to  the  I US  Program 


IUS  MISSION  CHARACTERIZATION 

EDD-IUS  FLIGHT  PROGRAM 

IUS  DOWNDATA  UPDATA  SIMULATION 

IUS  GND  SW  VALID  TEST  REQUIREMENTS 

OBTAIN  IUS  SYSTEM  CHARACTERISTICS 

DETERMINE  IUS  FAILURE  MODES 

IUS  DISPLAY  FORMAT  DESIGN 

IUS  MISSION  FAILURE  EFFECTS 

DESIGN  IUS  MISSION  SIMULATION 

ANALYZE  IUS  COMPONENT  CHARACTERISTICS 

IUS  TRAINING  REQ/CRIT/SIMSKED 

PREPARE  IUS  SYSTEMS  HANDBOOK 

PUBLISH/UPDATE  IUS  HANDBOOK 

DEVELOP  IUS  TRAINING  MATERIAL 

IUS  CLASSROOM  TRAINING 

IUS  NETWORK  DATA  HANDLING  REQUIREMENTS 

IUS  NETWORK  DATA  VALID  PROCEDURES 

IUS  NETWORK  DATA  VALID  TESTS 

PROGRAM  IUS  DNDAT A/ U P DAT A/ SIMULATION 

PROGRAM  IUS  FLIGHT  SOFTWARE 

VERIFY  IUS  DNDATA/UPDATA/SIM  PROGRAMS 

CONSOLE  POSITION  GUIDELINES 

IUS  MISSION  PLANNING  AND  OPTIMIZATION 

DEVELOP  IUS  PROCEDURES  AND  RULES 

IUS  ABORT  PLANNING 

IUS  INTERAGENCY  COORDINATION 

IUS  FLT  PROGRAM  VERIFICATION 

PREPARE  IUS  INTERAGENCY  DOCUMENTS 

PROGRAM  IUS  MISSION  SIMULATION 

IUS  MISSION  SPEC  EDD 

IUS  MISSION  SPEC  PROGRAM 

IUS  MISSION  PROGRAM  VERIFICATION 

IUS  MISSION  SIMULATION  TRAINING 

CONDUCT  IUS  MISSION  OPERATIONS 

IUS  POST  ‘MISSION  REPORTS 

DEFINE  IUS  OPERATOR  CERT/CRITERIA 

DEFINE  NETWORK  TRACKING  REQUIREMENTS 

NETWORK  TRACKING  VALID  PROCEDURES 

NETWORK  TRACKING  VALID  TESTS 
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Table  IQ  4 5-1  Elements  Unique  to  the  Space  Tug  Program 


OBTAIN  SPACE  TUG  SYSTEM  CHARACTERISTICS 

TUG  MISSION  CHARACTERIZATION 

EDD-TUG  FLIGHT  PROGRAM 

TUG  DOWNDATA  UPDATA  DOCKING  SIMULATION 

TUG  GND  SW  VALID  TEST  REQUIREMENTS 

DETERMINE  TUG  FAILURE  MODES 

TUG  DISPLAY  FORMAT  DESIGN 

TUG  MISSION  FAILURE  EFFECTS 

DESIGN  TUG  MISSION  SIMULATION 

ANALYZE  TUG  COMPONENT  CHARACTERISTICS 

TUG  TRAINING  REQ/CRIT/SIMSKED 

PREPARE  TUG  SYSTEMS  HANDBOOK 

PUBLISH/UPDATE  TUG  SYSTEMS  HANDBOOK 

DEVELOP  TUG  TRAINING  MATERIAL 

TUG  CLASSROOM  TRAINING 

TUG  NETWORK  DATA  HANDLING  REQUIREMENTS 

TUG  NETWORK  DATA  VALID  PROCEDURES 

TUG  NETWORK  VALID  TESTS 

PROGRAM  TUG  DNDATA/UPDATA/SIMULATION 

PROGRAM  TUG  FLIGHT  SOFTWARE 

VERIFY  TUG  DNDATA/UPDAT A/SIM  PROGRAMS 

TUG  CONSOLE  POSITION  GUIDELINES 

TUG  MISSION  PLANNING  AND  OPTIMIZATION 

DEVELOP  TUG  PROCEDURES  AND  RULES 

TUG  ABORT  PLANNING 

TUG  INTERAGENCY  COORDINATION 

TUG  FLT  PROGRAM  VERIFICATION 

PREPARE  TUG  INTERAGENCY  DOCUMENT 

PROGRAM  TUG  MISSION  SIMULATION 

TUG  MISSION  SPEC  EDD 

TUG  MISSION  SPECIFIC  PROGRAM 

TUG  MISSION  PROGRAM  VERIFICATION 

TUG  MISSION  SIMULATION  TRAINING 

CONDUCT  TUG  MISSION  OPERATIONS 

TUG  POST  MISSION  REPORTS 

DEFINE  TUG  OPERATOR  CERT/CRITERIA 
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10  5 UTILIZATION  OF  COMMON  OPERATIONAL  ELEMENTS 

The  most  cost-effective  approach  to  the  overall  space  transportation  system 
problem  in  the  upper  stage  area  is  to  maximize  the  utilization  of  operational 
support  elements  which  are  common  between  the  IUS  and  the  Space  Tug  program. 
The  key  to  maximizing  this  utilization  is  in  the  detail,  adequacy  and 
flexibility  of  the  initial  planning  effort. 

There  are  four  basic  plans  which  must  be  generated  in  detail  and  adhered  to 
in  execution.  Those  are  Facility  Utilization  Plan,  Flight  Software 
Development  Plan,  Ground  Software  Development  Plan,  and  the  Computer 
Utilization  Plan. 

The  Facility  Utilization  Plan  should  consider  those  programs  which  are 
co-resident  with  the  IUS  and/or  the  Space  Tug  program  within  the  same 
physical  plant. 

The  Flight  Software  Development  and  Ground  Software  Development  Plans 
should  be  constructed  to  include  all  flight  and  ground  software  for  both 
IUS  and  Space  Tug  programs.  A well  thought  out  plan  would  include  the 
utilization  of  modules  developed  for  mission  planning  in  the  ground 
software  as  tools  for  the  evaluation  of  the  flight  software 

The  Computer  Utilization  Plan  will  establish  a pre-emption  hierarchy  for 
utilization  of  the  computer.  The  computer  should  be  dedicated  to  mission 
control,  mission  planning,  and  flight  software  development,  with  the 
remaining  time  being  devoted  to  such  functions  as  batch  processing, 
payroll,  etc. 

Early,  detailed  and  adequate  planning  is  required  in  order  to  maximize  the 
utilization  of  the  common  support  elements. 

The  physical  plant  should  be  initially  designed  to  fit  the  maximum  require- 
ments of  all  programs  resident  within  the  physical  plant.  In  the  case 
of  the  IUS  and  Space  Tug,  the  Space  Tug  will  require  more  consoles  and 
more  personnel  than  the  Expendable  IUS.  Therefore,  the  initial  layout  of 
console  communications  groups,  display  devices,  and  etc.,  should  be  sized 
to  the  Space  Tug  requirements.  The  IUS  will  operate  on  a sub-set  of  the 
Space  Tug  system.  The  consoles  should  be  designed  to  be  compatible  with 
both  IUS  and  Space  Tug  requirements.  The  initial  layout  of  console  equip- 
ment should  be  established  early  and  would  ideally  be  the  result  of 
requirements  specified  by  both  IUS  and  Space  Tug  operational  personnel. 

The  consoles  will  be  installed  in  a fixed  relationship  which  will  not  be 
varied  in  the  transition  phase.  That  is,  a console  devoted  to  avionics 
display  and  control  in  the  IUS  program  will  be  dedicated  to  avionics  in 
the  Space  Tug  program  as  well.  Organizational  hierarchy,  which  to  an 
extent  influences  the  orientiation  and  selection  of  console  locations,  will 
be  be  constant  between  the  IUS  and  Space  Tug  programs.  The  consoles  will 
be  designed  so  that  the  display  formats  are  flexible.  The  background 
information,  engineering  unit  and  parameter  selections  should  be  software 
variable.  In  that  way,  deviation  in  parameter  names,  scales  and  relative 
position  on  display  will  be  functions  of  the  ground  software  programs, 
and  not  hardware.  The  presumption  is  that  it  is  always  easier  to  change 
software  than  to  change  hardware. 
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In  order  to  develop  a Transition  Plan,  we  first  constructed  a PERT  chart, 
and  then  performed  operations  on  that  PERT  flow  until  a comprehensive  de- 
velopment plan  was  established  for  both  the  IUS  and  the  Space  Tug  programs 
Figure  10  5 0-1  presents  the  PERT  chart  for  the  composite  program. 

The  PERT  chart  was  generated  by  the  IBM  mini -PERT  program  which  was 
designed  for  terminal  usage,  and  therefore  is  not  in  the  form  most 
frequently  seen  Briefly,  the  chart  consists  of  a series  of  event 
designators  displayed  across  the  top  of  the  chart,  and  strings  of  activties 
which  span  the  space  between  event  designators.  An  event  designator  may  be 
thought  of  as  being  equivalent  to  a "bubble"  on  the  more  frequently  seen 
PERT  chart.  The  significance  of  the  event  designator  is  that  it  represents 
a point  in  the  activity  flow  of  a program  which  must  be  reached  prior  to 
beginning  of  activities  "planned  ground  software  development"  before 
the  activity  generate  ground  software  equation  defining  document  may  begin. 

There  are  two  times  associated  with  each  event,  an  early  date  and  a late 
date.  These  dates  are  considered  to  be  either  starting  dates  or  finishing 
dates  depending  upon  whether  you  are  considering  the  activities  which  begin 
at  the  event,  or  activities  which  end  at  the  event  The  early  and  late 
dates  of  the  event  correspond  with  the  early  and  late  dates  of  the 
associated  activities  For  example,  for  event  26,  the  earliest  that 
activities  subsequent  to  event  26  can  begin  is  April  11,  1977,  which  is 
the  earliest  that  all  constraints  can  be  met.  And  September  18,  1978, 
is  the  latest  that  predecessor  activities  can  begin  without  impacting  the 
overall  schedule 

The  activity  is  bounded  on  each  end  by  an  event,  and  the  time  space  between 
the  event  is  determined  by  the  effort  that  must  be  applied  during  the 
activity.  An  activity  is  time  consuming  and  resource  consuming. 

Progression  of  activities  is  from  left  to  right  across  chart  with  vertical 
extensions  to  pick  up  parallel  activity  paths. 

There  exists  a path  which  constrains  the  earliest  date  the  project  can  be 
finished  as  a function  of  the  established  date  that  the  project  must  start 
This  path  is  called  the  "critical  path",  and  all  activities  in  the  program 
may  be  fit  within  the  constraints  of  the  beginning  and  ending  of  the 
critical  path.  In  generating  the  PERT  chart,  the  critical  paths  for  the 
IUS  and  Space  Tug  program  were  created  by  postulating  a first  mission  for 
the  IUS  in  April,  1981,  and  a first  mission  for  the  Space  Tug  in 
November,  1983.  These  postulates  establish  the  latest  possible  start 
time  for  (IUS  and  common)  elements  in  the  first  quarter  of  1977.  The 
initial  launch  of  Space  Tug  in  November,  1983,  requires  the  beginning 
of  the  Space  Tug  peculiar  efforts  in  February,  1982,  assuming  that  all 
of  the  common  development  has  been  completed  in  order  to  support  the 
IUS  program. 

A bar  chart  of  the  overall  program  is  presented  in  Fiqure  10.5  0-2.  The 
bar  chart  is  segregated  into  calendar  quarters  spanning  the  time  from  first 
quarter  1977  through  fourth  quarter  1983 
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Table  10.5  0-1  Man-Hour  Load  mo  of  DDT&E  Tasks  (Continued) 


CUT  PR  ED  SUCC 
DUR  DESC 


START 


FINISH 


22  23  11  /2  4/80  1 /19/81 

8.0  NE  WORK  TRACKING  VAIID  PR  0 C 


SA 

'3'2  0 0 


HOC 


1/19/81  3/16/81 


120.0 


8.0  NETWORK  TRACKING  VALID  TEST 


9 /1 1 /7  8 9 /10/7  9 4106  0 


5 2.0  PRCGR  M GR  OJND  TK/P  LAN  /EX  S 


9 /10  /79  5 /12  /80  27C65  0 


2033  .0 
2737  0 


3 5.0  VERIFY  EXE  CUTIVE  / TK  /PLAN  S 0 a- 
i 2 4 11  /27  /7  8 1 /0  8/79 

6,0  OBTAIN  SPACE  TUG  SYSTEM  CHA  - 


2 40.0 


26  25  26  7 /2  4/7  8 9 /1  8/7  8 

8 0 TUG  MISSION  CH  AR  ACTERI  ZATI 0 1 

27  II  n 9 /1  9 /80  3 /19  /82  16948  0 


7 8 0 EDD-TUG  FLIGHT  PROGRAM 


4/11  /77  9 /11/7  8 50977 .0 


7 4 0 EDD  - TUG  D OWNDATA  /UPD  AT  A/D  0 C 


6 40.0 
4 80 .0 


29-  7 195  8/06/82  10  /15  /82  4133.0 

10.0  TUG  GND  SW  VALID  TEST  REQUI  

30  *521  41 T 10/15/82  12/10/82 

8.0  DETERMINE  TUG  FAILURE  M CDES  

31  4 6 2 /05  /79  4/02/79 

8 0 TUG  DISPLAY  FORMAT  DESIGN  

3 2 41 T 5 T 12  /10  /82  2 /0  4/83  6 40.0 

8.0  TUG  MISSION  FAILURE  EFFECTS  

33  5 T 15  T 2 /0  4/83  4/2  9/83  4 80.0 

12.0  DESIGN  TUG  MISSION  SIMULATI  

34  5 T 5 1 21  3 /1  8/  83  4/29  /83 

6.0  ANALYZE  TUG  COMPONENT  OHARA  

3 5 5 T 13  T 4 /29  /83  6 /2  4/  83 

8.0  TUG  TRAINING  REO  / CRT  T /SIMSK  

3 6 51 T 5 2 T 4/2  9 /83  6 /2  4/83 

8.0  PREPARE  TUG  SYSTEMS  HANDBOO  

37  5 2 T 1 6 21-  6 /2  4/83  9 /16  / 83 

12.0  PUBLISH  /UPD  ATE  TUG  SYSTEMS  

3 8 13T  14  21  6 /2  4/83  8/19  /83 

8.0  DEVELOP  TUG  TRAINING  MATERI  

3 9 1 421  16T  8 /19  /83  9 /16  /83 

4.0  TUG  CLASSROOM  TRAINING  

40  IIOC  2 2 T 6 /10  /83  7 /0  8/83  160.0 

4 0 TUG  NETWORK  DATA  HANDLING  R 
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Table  1050-1  Man-Hour  Loading  of  DDT&E  Tasks  (Continued) 


320.0 


CUT  PEED  SUCC  START  FINISH  SA 

DVR  DESC 

41  22  T 23 T 7 / 0 8 / 83  9 /02  / 83  3 2 0.0 

8 0 TUG  NETWORK  DATA  VALID  PROC  

42  23  T 1 1OC  9 /0  2 / 83  10  /2  8/83 

8 0 TUG  NETWORK  VALID  TESTS  

43  N T 6 /12  /81  2 /12  /82  2411  0 


35  0 PROGRAM  TUG  DND  ATA/UPD  AT  A/D 


3 /19  /82  10  /0  8/82  "3  852.0 


29.0  PROGRAM  TUG  FLIGH  T S OF  TWARE 


2 /12/  82  10  /15  /82  24112.0 


3 5.0  VERIFY  TUG  DND  AT  A /UPD  AT  A /D  0 


960.0 


2 40.0 


46  27  5 T 11  /12  / 82  2 /04  /83 

12.0  TUG  CONSOLE  POSITION  GUIDE  L 

47  19  S HIT  12  /24/  82  2 /04/83  1920.0 

6.0  TUG  MISSION  PLANNING  AND  OP  

48  1 951  5 T 10  /15  /82  2/0  4/83  320.0 

16.0  DEVELOP  TUG  PROCEDURES  AND  

49  1112*  15  T 2 /0  4/83  4/2  9 /83  960.0 

12.0  TUG  ABORT  PLANNING  

50  21  T TIOC  9 /02/  83  10  /2  8/  83 

8.0  TUG  INTERAGENCY  COORD  IN  ATI  0 

51  T2  15  T 10/0  8/82  4 /29  /83  89  877.0 

2 9.0  TUG  FLT  PR  OGR  AM  VERIFI CATI 0 

52  15  T 21 T 7 /0  8/83  9 /02/83 

8 0 PREPARE  TUG  INTERAGENCY  DOC  

53  15  T 162  6 /2  4/83  9 /1 6 / 83  2 40.0 

12.0  PROGRAM  TUG  MISS  I ON  SIMU  LAT  

54  15  T 1 51 T 4/29/83  5 /27  /83  256  8 0 

4 0 TUG  MISSION  SPEC  EDD  

55  1512  152  2 5/27  /83  7 /22  /83  102  8 0 

8 0 TUG  MI  SSI  ON  SPE  CIFI  C PR  OGR  A 

56  152  2 16  2 7 /22  /83  9 /16  /83  5136.0 

8.0  TUG  MISSION  PROGRAM  VERIFI  C 

57  16  2 HOC  9 /16  /83  10  /2  8/  83  2 40  0 

6.0  TUG  MISSION  SIMULATION  TR  AT  

5 8 HOC  242  10  /2  8/83  11  /04  /83  40  0 

1.0  CONDUCT  TUG  MISSION  OPER  ATI  

59  242  TCYCL  11  /0  4 / 83  1 2 /30  / 83  320.,-Q 

8.0  TUG  POST  MISSION  REPORTS  

60  26  5 2 1 /07  / 83  2 /O  4/83 

4 0 DEFINE  TUG  OPERATOR  CERT/CR  
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Table  10  5 0-1  Man  Hour  Loading  of  DDT&E  Tasks  (Continued) 


CUT  FRED  SUCC  START  FINISH  SA 
DUR  DESC 

61  25  26  7 /2  4/7  8 9 /1  8/7  8 

8.0  IUS  MISSION  CHAR  ACTERIZATIO  

62  18  II  12  /11  /7  8 12  /10/79  9375. 

52  0 EDD+IUS  FLIGHT  PROGRAM  

63  7 9 9 /1  9/77  9 /11  /7  8 351  89  . 

5 2.0  EDD-IUS  DOWNDATA/UPD  ATA/SIM  

64  7 19  3 /2  4/80  5 /12/80  32  84. 

7.0  IUS  GND  SW  VALID  TEST  REQUI  • 

6 5 2 4 11  /27  /7  8 1 /08  /7  9 

6.0  OBTAIN  IUS  SYSTEM  CHARACTER  

66  4 41 J 3 /03  /80  4 /2  8/80 

8.0  DETERMINE  IUS  FAILURE  MODES  

67  4 6 2 /05  /79  4/02/79 

8.0  IUS  DISPLAY  FORMAT  DESIGN  

6 8 411  5 J 4/2  8/80  6 /23  /80  640 

8 0 IUS  MISSION  FAILURE  EFFECTS  

69  51  15J  6 /23  /80  9 /15  / 80  480. 

12  0 DESIGN  IUS  MISSION  SIMULATI  

70  5 J 51 J 8/0  4/80  9 /15  /80 

6.0  ANALYZE  IUS  COMPONENT  CH  AR  A 

71  51  13  J 9 /I  5/ 80  11 /1 0/80 

8.0  IUS  TRAINING  REQ  / CRIT  /SIMSK  

7 2 51 J 5 2 1 9 /15/  80  11  /1 0 / 80 

8.0  PREPARE  IUS  SYSTEMS  HAND  BOO  

7 3 5 21  1 6 J 11  /10  /80  2 /02  /81 

12.0  PUBLISH  /UPD  ATE  IUS  HANDBOOK  

7 4 1 3 J 141  11  /10  /80  1 /05  /81 

8 0 DEVELOP  IUS  TRAINING  M ATERI  

7 5 1 4J  161  1 /0  5 / 81  2 /O  2 / 81 

4.0  IUS  CLASSROOM  TRAINING  

76  6 2 21  10/27  /80  11  /24/  80  160 

4.0  IUS  NETWORK  DATA  HANDLING  R 

77  221  23 1 11  /2  4/80  1 /19  /81  320 

8.0  IUS  NETWORK  DATA  VALID  PR  OC  

7 8 2 3 J HOC  1/19/81  3/16/81 

8.0  IUS  NETWORK  DATA  VALID  TEST  

79  9 J 4/23  /7912  /24  /79  2739.0 

3 5.0  PROGRAM  IUS  DND  AT  A /UPD  A TA/S  

80  II  12  12  /10/79  4/2  8/80  2143  0 

2 0.0  PRuGRAM  IUS  FLIGHT  SOFTWARE  
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Table  10.5.0-1  Man-Hour  Loading  ofDDT&E  Tasks  ( Continued ) 


CM  T FRED  SUCC  START  FINfSH  SA 
DVR  DESC 

81  I 19  12  /2  4/79  5 /12  /80  14660.0 


156  4.  0 


2 0.0  VERIFY  IUS  DND  AT  A/UPD  AT  A/SI 
! 27  5 1 3 /31  /80  6 /2  3 /80 

12  0 COiS  OLE  POSITION  GUIDE  LIMES 


4 80,0  960  0 


14  40.0  14  40.0 


1111 


5 /12/80  6 /23  /80  1920.0 


6.0  IUS  MISSION  PLANNING  AND  OP 


5 / 26  / 80  9/15  / 80  220.0 


16.0  DEVELOP  IUS  PROCEDURES  AND 


111 I 15J 


6 /23  /80  9 /15  /80  960.0 


12.0  IUS  ABORT  PLANNING 


86  21 J HOC  1/19/81  3/16/81 

8.0  IUS  INTERAGENCY  COORD  IN  ATI  0 

87  12  15  J 4/2  8/80  9/15/80  42  857.0 

2 0.0  IUS  FLT  PROGRAM  VERIFI CATI  0 

88  1 5 J 21 1 11  /2  4/80  1 /19  /81 

8.0  PREPARE  IUS  INTERAGENCY  DOC  

89  15  J 16T  11  /10/  80  2/02/81  240.0 

12.0  PROGRAM  IUS  MISSION  SIMULA T 

90  1 5 J 1 5 1 J 9/15/80  10  /13/  80  21  43.0 

4.0  IUS  MISSION  SPEC  EDD  

91  1511  1521  10/13  /80  12  /0  8/80  857  .0 

8 , a zv$  on  $pkc  PFogqw  - 

92  152  J 16T  12  /0  6/  80  2 /02  /81  42  86.0 


857  .0 


4 80.0 


4 80.0 


3200.0 


I 1 

2 40 . 0 


2 40.0 


6 40 . 0 


320.0 


42  86 . 0 


320.0  12  80.0 
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IIOC  2 4 1 3 /16/  81  3 /23  /81 

1.0  CONDU  CT  IUS  MISSION  OPER  ATI 

2 4J  ICYCL  3/23/81  5/18/81 

8.0  IUS  POST  MISSION  REPORTS 

2 6 51-  5 /26  /80  6 /2  3 /BO 

4.0  DEFINE  IUS  OPERATOR  CERT/CR 
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The  information  in  Table  10  5 0-1  is  operated  upon  by  the  mim-PERT  pro- 
gram which  spreads  the  number  of  manhours  estimated  across  the  time  allocated 
for  the  accomplishment  of  a task.  The  program  selects  either  the  early 
(e)  acitivity  bars  or  the  late  ( L ) activity  bars.  It  was  elected  to 
spread  the  manhours  across  the  late  (l)  activities  because  it  is  felt  this 
represents  the  most  realistic  probability  for  the  availability  of  funds 
and  manpower  to  accomplish  the  IUS  and  Space  Tug  task.  It  is  an  easy 
option  to  select  the  early  ( E ) spread  should  NASA  so  desire. 

Table  10  5 0-2  presents  the  results  of  the  manpower  spread  across  the  PERT 
network  from  first  quarter  1977  through  the  fourth  quarter  1983  This 
chart  defines  the  type  of  skill  required  by  the  month  in  which  that  skill 
is  required  and  by  the  number  of  men  necessary  in  any  given  month  to 
accomplish  all  of  the  tasks  which  must  be  worked  during  that  month 
For  example,  in  May,  1977,  twenty  Systems  Analysts  are  required,  two 
Mission  Engineers  are  required,  two  Flight  Controllers  are  required,  and 
two  Flight  Support  personnel  are  required,  making  a total  of  twenty-six 
loaded  against  the  IUS/SPACE  TUG  program  during  that  month.  Monthly 
totals  and  totals  by  skill  are  provided  along  the  margins  of  the  yearly 
printouts 

The  manpower  distribution  is  surprisingly  flat  across  the  program  considering 
that  the  information  is  a first  iteration  analysis  The  next  step  is  then 
to  select  the  optimum  time  from  the  bar  chart  (Figure  10  5 0-2)  during  which 
the  optional  activities  may  be  scheduled  in  order  to  level  the  total 
manpower  requirements  within  a given  skill.  It  should  be  emphasized  that 
the  loading  of  manpower  is  against  the  DDT&E  schedule  and  does  not  include 
the  loading  for  recurring  manpower  efforts  in  support  of  the  IUS  program 
These  can  be  added  m at  a later  time  to  create  the  overall  picture. 
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Table  10  5 0-2  DDT&E Manpower  Requirements 


IUS /TUG  MISSION  OPERATIONS 
PRINTED  02/03  /75  AT  15  52  01 

MANPOWER  197  7 


CATEGORY 

JAN 

FEB 

MAR 

APR 

MAY 

JUN 

JUL 

AUG 

SYSTEMS  ANALYSTS 

0 0 

0 2 

4 0 

15 

4 

20 

0 

20 

0 

20 

0 

20 

0 

PROGRAM  MANAGEMENT 

3 0 

2 9 

0 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

MISSION  ENGINEERS 

0 0 

0 0 

0 0 

1 

4 

2 

0 

2 

0 

2 

0 

2 

0 

FLIGHT  PROGRAMMERS 
FLIGHT  CONTROLLERS 

0 0 

0 0 

0 0 

1 

4 

2 

0 

2 

0 

2 

0 

2 

0 

FLIGHT  SUPPORT  PERSO 

0 0 

0 0 

0 0 

1 

4 

2 

0 

2 

0 

2 

0 

2 

0 

GROUND  PROGR  ANMERS 

0 0 

0 1 

1 0 

0 

3 

0 

0 

0 

0 

0 

0 

0 

0 

ADMINISTRATORS 

1 0 

1 0 

0 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

MONTHLY  TOTALS 

4 0 

4 2 

5 0 

19 

9 

26 

0 

26 

0 

26 

0 

26 

0 

CATEGORY 

JAN 

FEB 

MAR 

APR 

MANPOWER 
MAY  JVN 

197  8 
JUL 

AUG 

SYSTEMS  AN  ALY STS 

2 8 7 

2 8 7 

2 8 7 

2 8 

7 

2 8 

7 

29 

3 

29 

4 

2 8 

7 

PROGRAM  MANAGEMENT 

0 0 

0 0 

0 0 

0 

0 

0 

0 

0 

7 

0 

7 

0 

0 

MISSION  ENGINEERS 

2 9 

2 9 

2 9 

2 

9 

2 

9 

4 

2 

5 

6 

7 

4 

F LI  GH  T PR  OGR  AMMERS 

0 0 

0 0 

0 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

FLIGHT  CONTROLLERS 

2 9 

2 9 

2 9 

2 

9 

2 

9 

2 

9 

3 

3 

4 

4 

FLIGHT  SUPPORT  PERSO 

2 9 

2 9 

2 9 

2 

9 

2 

9 

2 

9 

3 

1 

3 

6 

GROUND  PROGR  AMMERS 

0 0 

0 0 

0 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

ADMINISTR  ATORS 

0 0 

0 0 

0 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

MONTHLY  TOTALS 

37  4 

37  4 

37  4 

37 

4 

37 

4 

40 

0 

42 

1 

44 

1 

CATEGORY 

JAN 

FEB 

MAR 

APR 

MAIIP  OWER 
MAY  JUN 

1979 

JUL 

AUG 

SYSTEMS  ANALYSTS 

8 8 

11  2 

4 9 

4 

7 

5 

4 

5 

4 

5 

4 

5 

4 

PROGRAM  MANAGEMENT 

1 4 

0 7 

2 2 

0 

4 

0 

4 

0 

3 

0 

0 

0 

0 

MISSION  ENGINEERS 

3 2 

5 1 

3 5 

1 

9 

2 

3 

2 

2 

1 

9 

1 

9 

FLIGHT  PROGR  AMMERS 

0 0 

0 0 

0 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

FLIGHT  CONTROLLERS 

3 8 

39  0 

43  9 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

FLIGHT  SUPPORT  PERSO 

2 3 

22  9 

26  0 

0 

3 

0 

3 

0 

2 

0 

0 

0 

0 

GROUND  PROGR  AMMERS 

65  4 

65  4 

65  4 

77 

6 

10  8 

2 

10  8 

2 

10  8 

2 

10  8 

2 

ADMINISTRATORS 

1 0 

1 0 

1 5 

0 

1 

0 

1 

0 

1 

0 

2 

0 

2 

MONTHLY  TOTALS 

85  9 

145  3 

147  4 

86 

0 

117 

7 

117 

4 

116 

7 

116 

7 

CATEGORY 

JAN 

FEB 

MAR 

APR 

MANPOWER 
MAY  JUN 

19  80 
JUL 

AUG 

SYSTEMS  ANALYSTS 

21  5 

21  5 

29  2 

39 

0 

57 

6 

4 8 

5 

43 

5 

43 

5 

PROGRAM  MANAGEMENT 

0 0 

0 0 

0 0 

1 

0 

1 

5 

2 

1 

0 

0 

0 

0 

MISSION  ENGINEERS 

2 0 

2 0 

5 4 

8 

5 

11 

8 

12 

6 

6 

5 

8 

4 

FLIGHT  PR  OGR  AMMERS 

36  3 

36  3 

36  3 

31 

3 

0 

0 

0 

0 

0 

0 

0 

0 

5 

F UGH  T OON  TR  OILERS 

2 1 

2 1 

23  5 

26 

9 

26 

7 

23 

7 

5 

5 

2 4 

FLIGHT  SUPPORT  PERSO 

5 8 

5 8 

8 5 

12 

8 

7 

5 

8 

4 

7 

0 

8 

0 

GROUND  PROGRAMMERS 

5 0 

5 0 

5 0 

5 

0 

1 

6 

0 

0 

0 

0 

0 

0 

ADMINISTRATORS 

0 2 

0 2 

0 2 

0 

2 

0 

0 

0 

0 

0 

0 

0 

0 

MONTHLY  TOTALS 

72  9 

72  9 

108  1 

12  4 

7 

106 

7 

95 

3 

62 

5 

84 

4 

SEP 

OCT 

NOV 

DEC 

TOTAL 

25 

9 

2 8 

7 

2 8 

7 

2 8 

7 

211 

6 

0 

0 

0 

0 

0 

0 

0 

0 

5 

9 

2 

6 

2 

9 

2 

9 

2 

9 

20 

7 

2 

6 

2 

9 

2 

9 

2 

9 

20 

7 

2 

6 

2 

9 

2 

9 

2 

9 

20 

7 

0 

0 

0 

0 

0 

0 

0 

0 

1 

4 

0 

0 

0 

0 

0 

0 

0 

0 

2 

0 

33 

7 

37 

4 

37 

4 

37 

4 

2 83 

0 

SEP 

OCT 

DEC 

TOTAL 

B 

9 

1 

4 

5 

0 

4 

8 

251 

0 

0 

5 

0 

6 

0 

6 

2 

2 

5 

3 

4 

5 

1 

5 

0 

7 

1 

4 

39 

8 

0 

0 

0 

1 

1 

0 

0 

3 

1 

4 

1 

6 

0 

0 

1 

1 

6 

7 

34 

5 

1 

2 

0 

0 

0 

3 

1 

6 

27 

2 

46 

7 

65 

4 

65 

4 

65 

4 

2 42 

9 

0 

0 

0 

5 

0 

8 

0 

2 

1 

5 

63 

4 

69 

5 

74 

9 

82 

6 

603 

6 

SEP 

OCT 

NOV 

DEC 

TOTAL 

12 

1 

14 

4 

14 

4 

15 

8 

107 

9 

0 

0 

0 

0 

0 

4 

0 

4 

6 

2 

2 

3 

2 

4 

2 

4 

1 

9 

31 

0 

0 

0 

0 

0 

0 

0 

27 

6 

27 

6 

1 

0 

1 

0 

1 

0 

1 

3 

96 

0 

0 

0 

0 

0 

c 

3 

2 

0 

54 

3 

63 

0 

47 

9 

47 

9 

35 

6 

901 

0 

0 

2 

0 

2 

0 

5 

0 

5 

5 

6 

7 8 

6 

65 

9 

66 

9 

85 

1 

1229 

6 

SEP 

OCT 

DEC 

TOTAL 

26 

5 

8 

6 

7 

8 

14 

1 

361 

3 

1 

1 

2 

1 

1 

3 

1 

3 

10 

4 

5 

0 

2 

7 

7 

0 

8 

3 

80 

2 

0 

0 

6 

5 

1 0 

0 

2 

2 

15  8 

9 

13 

6 

4 

7 

11 

8 

17 

2 

1 82 

3 

4 

7 

2 

2 

8 

5 

11 

0 

90 

2 

0 

0 

0 

0 

3 

8 

5 

0 

30 

4 

1 

1 

2 

1 

2 

9 

4 

0 

10 

9 

52 

0 

2 8 

9 

53 

1 

63 

1 

92  4 

6 

Table  10  50-2  DDT&E  Manpower  Requirements  (Continued) 
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IV  S /TUG  MISSION  OPERATIONS 
PRINTED  02/03  /15  AT  15  55  10 


CATEGORY 

JAN 

FEB 

SYSTEMS  ANALYSTS 

15 

0 

4 

4 

PROGRAM  MANAGEMENT 

1 

8 

3 

8 

MISSION  ENGINEERS 
FLIGHT  PROGR  AMMERS 

6 

7 

2 

0 

FLIGHT  CON  QROLLBRS 

27 

S 

24 

0 

FLIGHT  SUPPOR  T PERS  0 

26 

0 

26 

0 

GROUND  PROGR  AMMERS 

5 

0 

0 

0 

ADMINISTRATORS 

2 

2 

0 

0 

MONTHLY  TOTALS 

84 

2 

60 

2 

CATEG  CRY 

JAN 

FEB 

SYSTEMS  AN  AH  STS 

4 

4 

9 

3 

PROGRAM  MANAGEMENT 

0 

0 

0 

0 

MISSION  ENGINEERS 

1 

S 

1 

8 

FLIGHT  PROGRAMMERS 

0 

0 

0 

0 

FLIGHT  CONTROLLERS 

1 

0 

1 

0 

FLIGHT  SUPPORT  PERSO 

0 

0 

0 

0 

GROUND  PROGRAMMERS 
ADMINISTR  ATGRS 

6 4 

3 

2 8 

9 

MONTHLY  TOTALS 

71 

2 

41 

0 

CATEGORY 

JAN 

FEB 

SYSTEMS  ANALYSIS 

56 

8 

54 

2 

PROGRAM  MANAGEMENT 

2 

5 

0 

8 

MISSION  ENGINEERS 

12 

5 

9 

0 

FLIGHT  PROGRAMMERS 

0 

0 

0 

0 

FLIGHT  CONTROLLERS 

10 

7 

19 

7 

FLIGHT  SUPPORT  PERSO 

8 

7 

3 

8 

GROUND  PROGRAMMERS 

0 

0 

0 

0 

ADMINISTRATORS 

0 

0 

0 

0 

MONTHLY  TOTALS 

91 

2 

87 

5 

MAR 

APR 

MANP  ONER 
MAY  JUN 

19  81 
JUL 

4 4 

4 

4 

3 9 

4 0 

4 4 

2 7 

1 

0 

0 5 

0 0 

0 0 

4 9 

11 

0 

6 2 

1 3 

1 5 

21  5 

11 

0 

6 2 

1 0 

1 0 

22  8 

10 

0 

5 2 

0 0 

0 0 

0 0 

0 

0 

0 0 

3 8 0 

64  3 

0 0 

0 

0 

0 0 

0 0 

0 0 

56  3 

37 

4 

22  0 

44  3 

71  2 

MAR 

APR 

MANP ONER 
MAY  JUN 

19  82 
JUL 

12 

9 

12 

1 

12 

1 

12 

1 

12 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

6 

1 

0 

1 

0 

1 

0 

1 

0 

14 

8 

37 

9 

37 

9 

37 

9 

37 

9 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

30 

3 

52 

1 

52 

1 

52  1 

52 

1 

MANPOWER 

1983 

MAR 

APR 

MAY 

JUN 

JUL 

53 

3 

53 

3 

10 

0 

2 9 

5 

5 

0 

0 

0 

0 

2 

0 

0 3 

1 

1 

10 

3 

11 

3 

1 

5 

4 0 

6 

3 

0 

0 

0 

0 

0 

0 

10  0 

7 

5 

30 

0 

40 

5 

4 

0 

6 3 

11 

8 

3 

0 

3 

0 

2 

0 

3 5 

8 

5 

0 

0 

0 

0 

0 

0 

1 3 

5 

0 

0 

0 

0 

0 

0 

0 

1 7 

3 

6 

96 

6 

108 

1 

19 

5 

30  0 

49 

3 

AUG 

SEP 

OCT 

NOV 

DEC 

TOTAL 

4 

4 

4 

4 

4 

4 

4 4 

4 

4 

62 

5 

0 

0 

0 

0 

0 

0 

0 0 

0 

0 

9 

8 

1 

5 

1 

5 

1 

5 

1 5 

1 

5 

41 

1 

1 

0 

1 

0 

1 

0 

1 0 

1 

0 

97 

2 

0 

0 

0 

0 

0 

0 

0 0 

0 

0 

90 

0 

64 

3 

64 

3 

64 

3 

64  3 

6 4 

3 

42  8 

8 

0 

0 

0 

0 

0 

0 

0 0 

0 

0 

2 

2 

71 

2 

71 

2 

71 

2 

712 

71 

2 

731 

6 

AUG 

SEP 

OCT 

NOV 

DEC 

TOTAL 

17 

0 

18 

1 

45 

2 

CO 

00 

-d- 

50 

5 

254 

6 

0 

0 

0 

0 

0 

0 

0 6 

1 

0 

2 

6 

1 

8 

2 

0 

5 

7 

8 0 

9 

3 

35 

7 

37 

9 

37 

9 

9 

0 

0 0 

0 

0 

251 

2 

1 

9 

2 

1 

13 

8 

25  8 

28 

5 

80 

5 

1 

6 

2 

0 

3 

6 

6 8 

8 

0 

22 

3 

0 

0 

0 

0 

0 

0 

0 0 

0 

0 

93 

2 

0 

0 

0 

0 

60 

2 

62 

1 

77 

3 

91  0 

97 

3 

740 

1 

AUG 

SEP 

OCT 

NOV 

DEC 

TOTAL 

11 

5 

5 

8 

1 

0 

l 3 

1 

0 

256 

6 

1 

2 

2 

9 

3 

4 

1 8 

1 

0 

17 

0 

7 

8 

2 

3 

1 

0 

10  3 

10 

0 

103 

3 

0 

0 

0 

0 

0 

0 

0 0 

0 

0 

17 

5 

20 

8 

22 

5 

22 

0 

17  S 

10 

0 

215 

8 

19 

3 

25 

0 

24 

0 

18  6 

10 

0 

129 

4 

5 

0 

2 

5 

0 

0 

0 0 

0 

0 

13 

8 

3 

8 

5 

0 

0 

0 0 

0 

0 

9 

6 

69 

4 

61 

5 

51 

4 

49  5 

32 

0 

763 

0 

10  6 COMPOSITE  IUS/SPACE  TUG  SUMMARY  COST  DATA 

Figure  10  6.0-1  presents  the  composite  IUS/Space  Tug  program  expenditures 
for  a 180  month  program  Based  on  a time  0 date  of  January  1977,  the  IUS 
will  become  operational  in  April  1981,  and  Space  Tug  will  become  opera- 
tional in  November  1983  The  IUS  Program  is  considered  to  be  over  at  the 
IOC  of  the  Space  Tug  Program 

The  composite  IUS/Space  Tug  Program  expenditures  exceed  $100  million  over 
the  program  life  The  curves  are  derived  by  adding  together  the  IUS  DDT&E 
expenditures  prior  to  April  1981,  the  Space  Tug  DDT&E  expenditures  prior 
to  November  1983,  and  the  IUS  recurring  cost  expenditures  between  April 
1981  and  November  1983,  and  the  Space  Tug  recurring  cost  expenditures  from 
November  1983  until  the  end  of  the  program 

Figure  10  6 0-2  presents  the  IUS  Program  and  Space  Tug  DDT&E  rate  of  expen- 
diture This  is  an  amplification  of  the  first  86  months  of  the  program 
In  Figure  10  6 0-2  the  IUS  Program  absorbs  the  hardware,  data  system,  ground 
software,  and  physical  plant  expenditures  The  actual  journal  mg  of  those 
expenditures  is  a Government  decision,  since  the  equipment  will  belong  to 
the  Space  Tug  Program  after  the  IUS  has  become  non-operational 

The  average  monthly  expenditure  over  the  86  month  composite  IUS  Program 
and  Space  Tug  DDT&E  is  approximately  $663,000.  This  includes  the  major 
hardware  expenditure  in  the  41st  month  of  $8  04  million 

Figure  10  6 0-3  presents  the  manpower  requirements  m equivalent  men-per- 
month  based  on  the  composite  IUS/Space  Tug  program  schedule  This  curve 
represents  manpower  expended  on  DDT&E  tasks  only  It  does  not  include  any 
estimate  of  manpower  required  to  conduct  IUS  operations  over  the  period 
from  April  1981  through  November  1983  In  any  event,  the  total  man-load 
over  that  period  should  not  increase  greater  than  60  additional  men  per 
month,  and  upon  entering  the  Space  Tug  operational  period  at  the  end  of  1983 
the  total  manning  will  drop  to  approximately  64 

The  man-loading  curve  presents  information  based  upon  assumptions  that  the 
schedule  is  loaded  such  that  each  task  is  performed  as  late  as  possible 
without  resulting  in  an  overall  slip  of  schedule  This  results  m a net 
right  shift  of  expenditure,  which  delays  funding  to  the  maximum  extent. 

It  should  be  noted  that  other  combinations  of  tasks  and  other  schedules 
are  possible  which  can  smooth  or  reduce  man-load  peaks.  Volume  IV  of  the 
Orbital  Operations  and  Mission  Support  Study  final  report  presents  a schedule 
bar  chart  which  identifies  the  available  rescheduling  options  to  the  NASA 


10-85 


MILLIONS  OF  DOLLARS 


COMPOSITE  I US/SPACE  TUG  PROGRAM  EXPENDITURES,  ORBITAL  OPERATIONS  AND  MISSION  SUPPORT 


0 20  40  60  80  100  120  140  160  180 


MONTHS  FROM  GO  AHEAD 


Figure  10  6 0-1  Composite  IUS/Space  Tug  Program  Expenditures  (00 /MS) 
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Figure  10  6 0-2  IUS  Program  and  Space  Tug  DDT&E  Rate  of  Expenditure  (00 /MS) 


Peak  loading  occurs  in  May  1979  This  is  225  6 equivalent  personnel.  The 
minimum  loading  occurs  in  May  1982  at  23  1 personnel  This  does  not  include 
IUS  operational  personnel  If  the  IUS  operational  personnel  are  included, 
then  the  minimum  number  of  personnel  applied  to  the  program  becomes  63  1 
in  May  1981 

Table  10  6 0-1  presents  a cost  summary  of  the  composite  IUS/Space  Tug 
DDT&E  expenditures  This  summary  was  derived  by  adding  togehter  the  com- 
posite program  costs,  then  identifying  definable  lost  of  cost,  such  as 


Table  1060-1.  Cost  Summary  Composite  DDT&E  Costs 


TOTAL  DEVELOPMENT  COST 

ELEMENT 

DOLLARS 

PHYSICAL  PLANT 

418620 

TOC  SOFTWARE  DEVELOPMENT 

18983200 

DATA  SYSTEM 

7010008 

OPERATIONS  STAFF  EQUIPMENT 

1052400 

IUS  SOFTWARE  DEVELOPMENT 

2729197 

TUG  SOFTWARE  DEVELOPMENT 

5058689 

SERVICE  ACTIVITIES 

5533614 

TOTAL 

40785728 

TOTAL  IUS  DDT&E 

27483428 

TOTAL  TUG  DDT&E 

27899738 

TOTAL  COMPOSITE  DDT&E 

55383136 

o 

(-)4G785728 

NET  SAVINGS 

14597438 

10-89 


physical  plant,  data  system,  operations  staff  equipment,  IUS  software  de- 
velopment, Space  Tug  software  development  and  ground  operation  center 
software  development  When  these  definable  tasks  were  subtracted  from 
the  composite  program  costs,  a residual  of  $5  53  million  was  obtained 
This  residual  is  composed  principally  of  manpower  expenditures  for  plan- 
ning and  coordination  efforts  On  Table  10.6  0-1  that  charge  has  been 
identified  as  service  activities 

It  is  of  interest  to  examine  net  savings  resulting  from  combining  the  IUS 
and  Space  Tug  DDT&E  expenditures  Table  10  6 0-1  demonstrates  that  $14  56 
million  are  saved  by  combining  IUS  and  Space  Tug  orbital  operations  and 
mission  support  functions  The  major  portion  of  those  savings  is  the  ground 
computer  software  development 

Figure  10  6 0-4  presents  the  IUS  program  cumulative  expenditures  Bear  in 
mind  when  examining  this  curve,  that  the  major  hardware  purchases  are  in- 
curred during  the  IUS  DDT&E  period  and  thus  bias  the  IUS  curve  upward 

Figure  10  6 0-5  presents  the  IUS  program  rate  of  expenditure  curve  This 
curve  was  shown  earlier  as  the  IUS  contribution  to  the  IUS  program  and 
Space  Tug  DDT&E  rated  expenditure  shown  in  Figure  10  6 0-2 

Figure  10  6 0-6  presents  the  Space  Tug  DDT&E  rate  of  expenditure  curve. 

This  curve  was  shown  earlier  as  the  Space  Tug  DDT&E  contribution  to  Figure 
10  6 0-2  The  Space  Tug  DDT&E  period  may  be  said  to  begin  in  January  1977 
along  with  the  IUS  program,  during  which  Space  Tug  peculiar  operational 
problems  are  being  worked  in  conjunction  with  the  similar  operational  problems 
of  the  IUS  The  major  portion  of  Space  Tug  effort  is  intentionally  delayed 
until  the  IUS  becomes  operational  in  order  to  avoid  excessive  overlap  of  the 
DDT&E  phases 

Figure  10  6.0-7  presents  the  Space  Tug  program  cumulative  DDT&E  expenditures 
It  should  be  noted  that  Space  Tug  program  costs  presented  on  this  curve  pre- 
sume the  IUS  program  has  borne  the  expenses  of  major  hardware  expenditures 
and  common  element  costs 

10  7 RECURRING  COSTS  - OPERATIONS 

Figure  10  7 0-1  presents  a schedule  of  recurring  tasks  which  will  be  followed 
for  each  flight  Man-loading  on  that  schedule  is  for  the  first  flight  oper- 
ation It  is  anticipated  that  the  sequence  of  operations  will  remain  pretty 
much  the  same  as  the  program  matures,  but  that  the  man-loading  of  each  task 
will  be  significantly  reduced  as  the  program  matures 

Figure  10  7 0-2  presents  a typical  mission  operations  cycle,  specifically 
man-loaded  for  the  initial  launch  operation  On  the  basis  of  Figure  10  7 0-2, 
the  first  launch  should  cost  NASA  $1  887  million  The  cost  of  the  first 
launch  operation  is  included  in  the  DDT&E  expense  presented  in  Section  10  6 
it  is  included  in  this  section  for  orientation  purposes  only.  The  actual 
cost  per  flight  should  be  computed  by  dividing  the  recurring  expenditures 
over  the  entire  program  by  the  total  number  of  IUS  and  Space  Tug  launches. 

This  gives  an  average  cost  per  flight  estimate  of  $375,800  per  flight 
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Figure  10.6  0-6.  Space  Tug  DDT&E  Rate  of  Expenditure  Curve  (00/MS) 
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Figure  10. BO-7  Space  Tug  Cumulative  DDT&E  Expenditures  (00 /MS) 
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Figure  10.70-1  Schedule  of  Recurring  Tasks  (00 /MS) 


One  is  tempted  to  apply  an  exponential  learning  curve  to  the  flight  oper- 
ation effort  This  should  not  be  done,  since  the  flight  operations  will 
be  handled  on  a level  of  effort  basis  The  learning  curve  could  only 
apply  to  equivalent  man  months  per  month  and  could  never  fall  below  the 
level  of  sustaining  flight  control  and  flight  support  engineering  personnel 
costs 

Table  10  7 0-1  presents  the  cost  summary  for  composite  recurring  IUS  and 
Space  Tug  expenses  Table  10.7.0-1  assumes  there  is  no  overlap  of  IUS  and 
Space  Tug  operations  Costs  developed  for  the  IUS  program  apply  from  April 
1981  to  November  1983,  and  the  costs  derived  fro  the  Space  Tug  program  apply 
from  November  1983  to  the  end  of  the  program.  Examination  of  the  mission 
model  indicates  a possibility  that  the  IUS  may  continue  to  be  utilized  during 
a period  which  is  predominately  Space  Tug  oriented  If  such  is  the  case, 
there  will  be  no  increase  in  recurring  costs  over  the  level  required  for 
Space  Tug  operations,  under  the  assumption  that  the  same  personnel  will  be 
utilized  to  control  the  Space  Tug  as  were  utilized  to  control  the  IUS,  and 
that  the  IUS  unique  ground  software  is  available  in  off-line  storage 
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Table  10 JO-1  Composite  lUS/Space  Tug  Recurring  Expenses 


1 NO  OVERLAP  OF  IUS  AND  SPACE  TUG  OPERATIONS 

IUS  RECURRING  COSTS  APPLY 

FROM  APRIL  1981  TO  NOVEMBER  1983 

SPACE  TUG  RECURRING  COSTS 

APPLY  FROM  NOVEMBER  1983  TO  END  OF 

PROGRAM 

• IF  IUS  OPERATIONS  OVERLAP  SPACE  TUG 

OPERATIONS, 

NO  INCREASE  ABOVE  SPACE  TUG  OPERATIONS  COST  LEVEL 

RECURRING  COSTS 

ELEMENT 

DOLLARS 

FACILITY  MAINTENANCE 

19672 

TOC  SOFTWARE  MAINTENANCE 

1104000 

DATA  SYSTEM  MAINTENANCE 

134458 

SUSTAINING  TOC  ENGINEERING 

1584000 

SUSTAINING  TOC  FLT  ON  TL  ENGINEERING 

1440000 

NETWORK  RENTAL 

204755 

TUG  SOFTWARE  MAINTENANCE 

1008000 

TOTAL 

5494885 

FACILITY  MAINTENANCE 

19872 

TOC  SOFTWARE  MAINTENANCE 

1200000 

DATA  SYSTEM  MAINTENANCE 

138795 

SUSTAINING  TOC  ENGINEERING 

1440000 

SUSTAINING  TOC  FLT  ON  TL  ENGINEERING 

1440000 

NETWORK  RENTAL 

26233 

IUS  SOFTWARE  MAINTENANCE 

1008000 

TOTAL 

5272900 
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POTENTIAL  PROBLEM  AREA  SUMMARY  TT 

The  Orbital  Operations  study  defined  items  which  appear  to  be  potential  pro- 
blem areas  for  Tug  operations  and  other  areas  require  further  consideration  or 
analysis  A summary  of  such  items  are  included  in  this  section 

• JSC’s  Orbi ter/ Payload  Interface  is  Information  Only  - JSC's  Volume 

XIV  Space  Shuttle  System  Payload  Accommodations  Chg  7 was  released 
but  for  information  only  This  version  of  the  avionics  section 
finally  contained  enough  detail  to  address  interface  problems  JSC 

was  contracted  about  a Tug  interface  problem  and  indicated  the  entire 
Orbi ter/ Payload  interface  was  "INFO  ONLY"  It  will  be  a baseline 
from  which  to  solicit  comment  for  approximately  1 year 

The  Orbiter/Tug  interface  should  be  studied  and  defined  from  Tug 
"Orbital  Operation"  standpoint  to  another  level  of  detail  to  further 
quantify  the  requirements  to  which  the  Orbiter  must  eventially  be 
built  IUS  transition  must  also  be  considered  and  optimum  data 
transfer  techniques  defined,  such  as  addressed  in  the  next  concern 

• Interface  Data  Transfer  Concern,  Orbiter  and  Ground/Payload  Up  Link 
Bit  Rate  and  Coding  Requirements  Definition  - The  Orbiter  to  Payload 
command  link  bit  rate  is  sometimes  defined  as  2 0 Kbps,  2 4 Kbps, 

6 4 Kbps  and  8 0 Kbps  These  numbers  are  all  correct  depending  upon 
what  portion  of  the  total  message  is  the  basis  for  the  bit  rate 
The  root  is  a 50  command  per  second  capability  This  50  times  the 
40  bit  command  data  word  cross  the  Orbi ter/Payload  interface  is  the 
2 0 Kbps  If  the  definition  includes  the  address,  there  is  4 bits  of 
vehicle  address  and  4 bits  of  system  address  which  adds  4 Kbps  and 
the  bit  rate  is  2 4 Kbps  Next  the  command  bit  stream  is  BCH  encoded 
which  adds  77  parity  bits  and  3 dummy  bits  for  a total  of  128  and  the 
bit  rate  is  6 4 Kbps  Before  transmission  a 32  bit  sync  is  added 
which  results  in  a 160  bit  word  and  a 8 Kbps  bit  rate  This  is  all 
based  on  a 50  command  message  per  second  rate  of  transfer 

The  BCH  coding  scheme  is  the  same  as  used  on  the  ground  before 
transmission  to  the  Orbiter  Therefore  the  Orbiter  decodes  the 
command  and  if  the  address  identifies  it  as  a payload  command  the 
GPC  forwards  it  to  the  payload  interface  via  the  MDMs  and  PSPs. 

Within  the  PSP,  (BCH)  re-encoding  takes  place  if  the  total  trans- 
mission bit  rate  is  to  be  8 Kbps  If  it  is  something  less,  the 
re-encoding  will  be  done  within  the  GPC  as  specified  by  the  payload 
This  means  the  encoding  will  be  custom  designed  for  payloads  and  now 
is  a software  function  This  will  typically  lower  the  encoding 
overhead  for  the  slower  rates  However,  it  must  now  be  defined, 
coordinated  with  OSC  implemented  software  and  may  or  may  not  be  the 
lowest  cost  approach 

Therefore,  what  is  clearly  required  is  an  Uplink  Command  Requirement 
definition  study  to  define  attached  and  detached  commanding,  both 
in  terms  of  bit  rate  max  and  coding  required  to  ensure  proper  trans- 
mission Then,  an  implementation  trade,  to  see  how  best  to  meet 
requirements  for  the  least  program  cost 
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^Theval  of  a Disabled  Tug  - The  Orbital  Operations  study  did  not 
include  the  analysis  for  retrieval  of  a disabled  Tug  (or  Spacecraft) 
if  it  is  in  an  orbit  which  is  acessable  to  the  Orbiter  An  example 
would  be  the  failure  of  the  Tug  prior  to  its  first  mainstage  burn 
This  area  should  be  studied  to  determine  if  a retrieval  capability 
for  the  Tug  is  justified. 

• Spacecraft  Orbiter  Impacts  - The  Tug  Orbiter  software  impacts  were 
investigated  by  the  study,  but  the  Spacecraft  software  impacts 
on  the  Orbiter  were  not  The  Spacecraft  impacts  should  be  assessed 
to  determine  the  total  Tug  and  Spacecraft  impacts  on  the  Orbiter 

t Tug  Impacts  TDRSS  Usage  - The  TDRSS  user  support  requirements  will  be 
varied  For  instance,  the  Tug  16  Kbps  requirement  can  be  met  by  the 
Multiple  Access  system  However,  a 64  Kbps  requirement  during  burn 
periods  may  preclude  the  use  of  the  MA  system  by  the  Tug,  primarily 
because  bandwidth  requirements  would  limit  the  use  of  the  TORS  MA 
system  by  other  users  The  same  reasoning  applies  to  the  onboard 
recorder  dumps,  which  is  expected  to  be  at  64  on  256  Kbps  The 
most  obvious  solution  is  to  require  the  Tug  to  interface  with  the 
S-Band  single  access  system  during  burns  and  onboard  recorder  dumps 
At  this  time  the  MA  user  can  interface  with  the  SSA  system  with  a 
minimal  hardware  impact  However,  this  should  be  pursued  in  greater 
detail  due  to  the  significance  of  the  requirement  See  discussion 
in  Section  834 

9 The  Baseline  Tracker  Acquisition  Range  is  Apparently  Inadequate  for 
Pre-TPI  Acquisition  - Small  navigation  dispersions  and  a TPI  impulse 
budget  larger  than  the  examples  shown  m Section  7 2 may  ease  the 
requirement  for  longer  acquisition  ranges  but  additional  analysis 
is  required 

9 Final  Braking  Definition  - The  implementation  of  the  final  braking 
before  Docking  Inspection  and  Alignment  commences  may  be  implemented 
under  phase-plane  control,  i e , a smooth  distributed  impulse  range- 
rate  solution  rather  than  a discrete  burn  As  mentioned  previously 
in  Section  7 2,  the  feasibility  of  this  approach  must  be  defined  with 
more  sophisticated  techniques  than  were  employed  in  this  study 

9 Impulse  Budget  Refinement  - Analysis  of  non-optimal  Lambert  transfers 
should  be  undertaken  as  soon  as  possible  because  that  class  is 
actually  more  likely  than  optimal  transfers  The  APS  impulse  budget 
for  rendezvous  and  docking  appears  to  drive  the  rendezvous  tracker 
acquisition  range  requirement  Additional  and  continuing  refinement 
of  the  impulse  budget,  therefore,  is  required 

9 Simulation  of  Tug  Body  Dynamics  - A detailed  simulation  of  Tug  body 
dynamics  during  docking  to  assess  the  effects  of  slosh  on  APS  fuel 
usage  and  the  effect  of  impact  dynamics  on  Tug  translational  and 
rotational  control  is  required  to  support  analysis  of  the  docking 
parameters  See  Section  7 2 

9 Proposed  Requirements  - The  following  requirements  have  been  identified 
from  the  analysis  of  the  Space  Tug  operations  and  are  proposed  to  be 
added  to  the  baseline  See  Section  2 0 
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1 A system  level  checkout  requirement  is  needed  Consistent 
with  Level  II  autonomy  Tug  design  baseline  and  with  the  state- 
of-the-art  in  Built-m-Test-Equipment  (BITE),  it  is  a Tug 
requirement  to  be  primarily  responsible  for  system  level  check- 
out as  part  of  redundancy  management  The  Tug  Operations 
Center  (TOC)  will  be  primarily  responsible  for  detailed  Tug 
status 

2 A classified  payload  handling  requirement  is  needed.  In  the  event 
a classified  payload  is  retrieved  it  may  be  desirable  to  remove 
part  or  all  of  it  from  the  Tug  while  in  the  cargo  bay  Some 
form  of  requirement  will  be  necessary  to  handle  such  a situation. 
In  general,  no  requirement  addresses  just  what  the  Orbiter  is  to 
do  with  classified  payloads  This  situation  could  impact  mission 
planning  if  the  Tug  were  ever  required  to  deploy  an  unclassified 
but  retrieve  a classified  payload 

3 Maintain  LQo  + LHp  to  run  fuel  cells  for  4-5  hours  following 
propellant  clumps  c The  fuel  cells  are  required  to  power  the 
communications,  telemetry,  IMU  and  DMS  until  after  Tug  recovery 
by  the  Orbiter 

4 Autonomous  navigation  requires  ILT  or  equivalent  Autonomous 
navigation  is  cost  effective  because  it  is  independent  of  ground 
support  costs  ILT  is  proven  to  be  the  most  accurate  means  of 
navigation  update 

5 Rendezvous  and  Docking  Sensor  Range  (75-100  NM)  minimum  @ TPI. 

This  requirement  results  in  minimum  expenditure  of  APS  fuel 

6 Fuel  Cells  activated  during  prelaunch  to  supply  Tug  power  thru 
ascent  and  on-orbit  operations  The  Tug  power  requirements 
exceed  that  available  from  the  Orbiter  and  therefore  require 
full  Tug  mission  duration  use  of  its  fuel  cells. 

7 Telemetry  from  Tug  to  Orbiter  and  Tug  to  Ground  must  be  the  same 
This  will  allow  one  set  of  software  to  be  used  to  encode  and 
decode  the  telemetry  for  the  various  types  of  processing  that 
will  be  required 

8 Uplink  (command)  formats  from  ground  thru  Orbiter  to  Tug  and 
from  ground  to  Tug  must  be  the  same  This  will  allow  use  of 
one  set  of  software  and  or  hardware  encoders  and  decoders  on 
the  ground  and  onboard  the  Orbiter  and  the  Tug 

9 Orbiter  to  Tug  RF  must  be  established  prior  to  umbilical  dis- 
connect This  is  required  to  assure  the  safety  of  the  Orbiter 
and  its  ability  to  control  the  Tug  once  it  is  free  flying 

10  Design  Goal  - IUS  and  Tug,  telemetry  and  command  formats  should 
be  the  same  or  similar  This  is  required  to  allow  ease  of 
transition  i.e  , personnel  training,  reuse  of  some  procedures. 
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reuse  of  software  and  or  hardware  encoders  and  decoders  on  the 
ground  and  onboard  the  Orbiter,  the  IUS  and  the  Tug 

11  360  degrees  antennas  radiation  for  both  telemetry  and  command 
This  is  required  for  safety  to  allow  minimum  attitude  constraint 
between  Tug  and  the  Orbiter  (whose  violation  will  result  in 
communications  dropouts)  while  the  Tug  is  operating  close  to,  and 
is  a hazard  to,  the  Orbiter 

12  On-orbit  target  update  capability  is  required  As  part  of 
contingency  planning,  to  accommodate  a variety  of  partly  failed 
hardware  situations,  it  will  be  necessary  to  do  a target  update 
on-orbit 

t Baseline  Requirements  Concerns  - The  following  baseline  requirements 
are  those  which  can  not  be  or  are  not  being  implemented  With  each 
stated  requirement  is  given  the  reason  for  concern,  the  options  to 
alleviate  the  concern  and  the  recommendation  to  close  out  the  issue 
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OTI-2-17-139  A Tug  automatic  caution  and  warning  system  will  be 

provided  to  alert  the  Orbiter  to  hazardous  conditions 
in  the  Tug  when  attached  or  within  TBD  miles  of  the 
Orbiter  This  system  shall  interface  with  the 
standard  Orbiter  caution  and  warning  displays 
and  warning  devices 

0TI-29-1Q-45  (1)  All  subsystems  except  primary  structure  and 

pressure  vessels  shall  be  designed  to  fail  safe  in 
the  vicinity  of  the  Shuttle  Orbiter 


(2)  All  safety  subsystems  shall  be  designed  to 
fail  operational  in  the  vicinity  of  the  Shuttle 
Orbiter 


• Concern 


- Detached  Tug  C&W  data  flow  path  is  simplex  at  Orbiter 
Payload  Data  Interleaver  as  presently  defined 

• Options 

- Orbiter  design  change  to  implement  redundant  data 
paths  thru  Payload  Data  Interleaver 

• - Procedural  change  to  implement  an  Orbiter  evasive 

maneuver  to  safe  distance  and  ground  activation, 
checkout  of  Tug/Spacecraft 

If  checkout  OK  then  proceed  with  mission. 

If  checkout  not  OK  then  ground  will  safe  Tug/Space- 
craft and  Orbiter  will  retrieve  Tug/Spacecraft  if 
possible 
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• Recommendation 

- Procedural  change  provides  satisfactory  technical 
solution 

Requirement  No  3 

0TI-3-17-140  Design  Tug  so  it  can  be  jettisoned  in  orbit  by 
command  from  Orbiter  or  ground  for  emergency 
reasons  Provide  emergency  deploy  and  release  of 
Tug  to  Orbiter  connections 

• Concerns 

- Currently  not  in  baseline  design 

- IBM/GDC-I/MSFC  have  discussed  issue  and  have  assumed 
jettison  equates  to  normal  Tug  deployment 

- What  is  minimum  deploy  time  for  emergency  conditions 

- Are  there  Tug  system  failures  which  can  manifest 
themselves  prior  to  the  minimum  deploy  time7 

t Recommendations 

- JSC/MSFC  should  define  minimum  deploy  time  for 
emergency  conditions 

- Space  Tug  studies  should  define  system  failures  that 
could  occur  prior  to  minimum  time  and  design  pro- 
tection against  identified  failures 


- Delete  Requirement  No  3 
Requirement  No  20 

0TI-20-10-51  The  proper  functioning  of  the  interface  between  the 
STS  and  Tug  shall  be  maintained  under  all  nominal, 
contingency,  and  emergency  operations  of  either 
the  STS  or  the  Tug 

• Concern 

- Detached  Tug  data  flow  path  is  simplex  at  Orbiter 
Payload  Data  Interleaver 

• Options 

- Orbiter  design  change  to  implement  redundant  data 
paths  thru  Payload  Data  Interleaver 


• - Procedural  change  (same  as  Requirement  No  2 and 

29) 

• Recommendation 

- Procedural  change  (same  as  Requirement  No  2 and 
29) 

4 Requirement  No  27 

0TX-27-10-28  The  Tug  shall  not  initiate  its  propulsion  system 
until  a safe  separation  distance  and  attitude 
relationship  between  Orbiter  and  Tug  is  achieved 
The  Tug  propulsion  system  shall  not  cause  impringe- 
ment  of  exhaust  gases  that  would  be  harmful  to  the 
Orbiter 

• Concerns 

- APS  will  be  activated  shortly  after  physical 
depl oyment 

- It  is  assumed  the  requirement  statement  is  applicable 
to  mam  propulsion  system  only 

• Recommendations 

- Restate  requirement  for  application  to  mam  pro- 
pulsion system  only 

5.  Requirement  No  44 

OTI -44-10-63  Tug  critical  command  and  control  circuitry  shall 
be  designed  to  be  fail  operational /fail  safe  as 
a minimum 

t Concerns 

- Requirement  statement  for  fail  operational /fail 
safe  stated  m MSFC  Baseline  document 

- First  Data  Exchange  recommendation  was  stated  as 
"No  Single  Point  Failure  Shall  Result  in  a Hazard 
Which  Jeopardizes  the  Flight  or  Ground  Crew" 

- No  indication  of  fail  safe  design  in  Avionics  or 
interface 

9 Recommendation 

- MSFC  needs  to  restate  current  requirement  for 
contractor  guidance 
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6-  Requirement  No  45 


OTI -45-10-63  Tug  autonomous  navigation  commands  for  attitude 
control  and  translation  maneuvers  shall  be  dis- 
abled until  a safe  separation  distance  and 
compatible  trajectories  can  be  verified 

• Concerns 

- APS  (attitude  hold)  will  be  activated  shortly  after 
physical  deployment 

- Requirement  statement  implies  no  commands  for 
attitude  holds 

• Recommendation 

- Restate  requirement  to  exclude  attitude  hold 
activation 
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APPENDIX  n 


1 0 ORBITER/TUG  INTERFACE  REQUIREMENTS  DELETED 

The  following  eighteen  baseline  requirements  were  among  those  listed  early  in 
this  study  for  assessment,  as  having  potential  impact  on  the  Orbiter/Tug  inter- 
face design  from  an  Orbital  Operations  standpoint  The  eighteen  presented  here 
were  assessed  and  found  to  be  operationally  duplicates  or  having  no  impact  on 
Orbital  Operations  functions  They  have  been  deleted  from  further  consideration 
by  this  study  Reasons  for  deletion  accompany  each  requirement  statement 

0TI-13-10-66  Provisions  shall  be  made  for  safing  on  command  unused  explosive 

devices  aboard  the  Tug  and  safing  verification  sent  to  the  Orbiter 
prior  to  retrieval 

Reason  for  deletion  - No  explosive  devices  aboard  Tug 
0TI-16-10-63  Intentionally  left  blank. 

Reason  for  deletion  - No.  16  was  a duplicate  discovered  early  in  study 

OTI-31-10-45  Alternate  or  redundant  means  of  performing  a critical  function 
shall  be  physically  separated  or  protected  such  that  an  event 
which  causes  the  loss  of  one  means  of  performing  the  function 
will  not  result  in  the  loss  of  alternate  or  redundant  means 

Reason  for  deletion  - No  operational  requirement  - physical  design  requirement 

OTI-41-10-61  Redundant  fluid  or  electric  supply  lines  shall  not  be  located 
near  the  primary  line  containing  that  commodity 

Reason  for  deletion  - No  operational  requirement  - mechanical  design  requirement 

0TI-46-10-63  Tug  autonomous  control  commands  for  attitude  control  and  trans- 
lation maneuvers  shall  be  disabled  until  a safe  separation  dis- 
tance and  compatible  trajectories  can  be  verified 

Reason  for  deletion  - Duplicate  to  No  18 

OTI-A7-10-64  Electrical  umbilical  disconnects  between  the  Orbiter  and  the  Tug 
and  between  the  Tug  and  Spacecraft  shall  be  separated  from  haz- 
ardous fluid  disconnects,  shall  be  qualified  as  explosion  proof, 
and  shall  not  have  power  applied  during  disconnect 

Reason  for  deletion  - No  operational  requirement  - system  design  requirements. 

0TI-48-10-64  Power  circuits  shall  be  separated  from  critical  pyrotechnic  cir- 
cuits within  a cable  or  wire  bundle 

Reason  for  deletion  - No  operational  requirement  - no  pyrotechnics 

0TI-49-10-64  Tug  structure  shall  be  grounded  to  Orbiter  structure  to  prevent 
electrostatic  charge  buildup  and  an  electrical  shock  hazard 
Within  the  Tug  grounding  shall  be  such  as  to  preclude  an  elec- 
trical shock 
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Reason  for  deletion  - No  operational  requirement  - electrical  design  requirement 

OTI -50- 10-64  Safety  critical  electrical  and  electronic  components  shall  be 
potted,  hermetically  sealed  or  similarly  protected  against  the 
effects  of  liquid  leakage,  moisture  condensation,  vibration  and 
arcing  contacts 

Reason  for  deletion  - No  operational  requirement  - packaging  requirement 

OTI- 51- 10-64  Capability  shall  be  provided  for  static  discharge  between  Tug 
and  Orbiter  and  between  the  Tug  and  Spacecraft. 

Reason  for  deletion  - No  operational  requirement  - electrical  design  requirement 

0TI-52-10-64  The  return  of  current  to  the  power  source  shall  be  accomplished 
by  means  other  than  the  Tug  structure. 

Reason  for  deletion  - No  operational  requirement  - electrical  design  requirement. 

TOI-53-IO-64  Safety  critical  control  circuits  shall  be  capable  of  being 
verified. 

Reason  for  deletion  - Duplicate  to  No  15 

0TI-54-10-65  The  arming  of  pyrotechnic  devices  shall  be  protected  against 
accidental  operations 

Reason  for  deletion  - No  pyrotechnics  on  Tug. 

OTI -55- 10-65  Positive  indications  of  Tug  electrical  systems  shut  down  status 

shall  be  provided  to  the  Orbiter  flight  crew,  prior  to  retrieval 

Reason  for  deletion  - Duplicate  to  No.  14 

0TI-56-1Q-71  Provisions  shall  be  made  for  verifying  critical  Spacecraft  sys- 
tems readiness  before  activation 

Reason  for  deletion  - No  Tug/Orbiter  operational  requirement  - SC  system  veri- 
fication requirement 

OTI -58-10-74  No  single  operation  shall  result  in  flow  of  propellant  through 
the  Spacecraft  propulsion  system  The  APS  shall  be  inhibited 
while  in  the  Orbiter  payload  bay 

Reason  for  deletion  - No  Tug/Orbiter  operational  requirement  - SC  propellant 

system  requirement  and  SC/Tug  interlock  requirement. 

0TI-59-10-74  Spacecraft  sequencing  control  for  attitude  hold  and  mam  engine 
starting  sequence  shall  be  remotely  code  commanded  by  the  Orbiter 
crew  or  ground  control  Interlocks  shall  be  provided  to  prevent 
inadvertent  operations  of  the  Spacecraft  while  in  the  Orbiter 
payload  bay  or  during  the  deployment  phase  of  operation 
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Reason  for  deletion  - No  Tug/Orbiter  operational  requirement  - SC/Orbi.ter  inter- 
face while  detached  and  SC/Tug  interlock  requirement 

0TI-63- 10-77  Provisions  shall  be  included  for  Spacecraft  caution  and  warning 
functions  which  will  provide  both  audible  and  visual  warning  to 
Orbiter  crew  of  hazardous  situations  while  the  Spacecraft  is 
aboard  the  Orbiter  or  being  deployed 

Reason  for  deletion  - Redundant  with  requirement  No  12 
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2 0 PAYLOAD/TUG  INTERFACE  REQUIREMENTS  DELETED 


The  following  21  baseline  requirements  were  among  those  listed  early  in  this 
study  for  assessment,  as  having  potential  impact  on  the  Payload/Tug  interface 
design  from  an  Orbital  Operations  standpoint.  The  21  presented  here  were  as- 
sessed and  found  to  be  operationally  duplicates  or  having  no  impact  on  Orbital 
Operations  functions  They  have  been  deleted  from  further  consideration  by 
this  study  Reasons  for  deletion  accompany  each  requirement  statement 

PTI-5-10-20  The  Tug  (after  Orbiter  release)  shall  have  a limited  capability 
to  relay  SC  systems  status  to  the  SC  operations  center  or  relay 
SC  operations  center  commands  to  the  SC 

Reason  for  deletion  - Operationally  contained  in  requirement  No  7 

PTI-10-10-20  The  Tug  shall  relay  via  the  Orbiter  SC  operations  center  control 
commands  to  the  SC  as  required  for  mission  preparations  Orbiter 
safety  related  commands  to  the  SC  shall  be  relayed  to  the  SC 

Reason  for  deletion  - Operationally  contained  in  requirement  No  7 

PTI-15- 10-45  Alternate  or  redundant  means  of  performing  a critical  function  shall 
be  physically  separated  or  protected  such  that  an  event  which  causes 
the  loss  of  one  means  of  performing  the  function  will  not  result  in 
the  loss  of  alternate  or  redundant  means. 

Reason  for  deletion  - System  design  requirement  only 

PTI- 16- 10-45  Mission  critical  single  failure  points  will  be  minimized  to  the 
maximum  extent  possible 

Reason  for  deletion  - System  design  goal  only 

PTI- 17- 10-46  Isolation  of  anomalies  of  mission  and  crew  essential  functions  will 
be  provided  to  assure  a failure  will  not  propagate  across  any  in- 
terface 

Reason  for  deletion  - System  design  goal  only 

PTI- 18-10-54  All  mechanical,  electrical  and  fluid  connections  between  the  Tug 
and  Spacecraft  and  Orbiter  shall  be  fail  safe. 

Reason  for  deletion  - System  design  requirement  only 

PTI-19-10-70  Any  Spacecraft  subsystem  operation  which  impacts  safety  during  the 
launch  and  entry  phases  shall  be  monitored  via  C&W  (caution  and 
warning)  and  controlled  from  the  Orbiter  flight  station 

Reason  for  deletion  - This  requirement  is  contained  in  requirements  No  9 and 
No  13 

PTI-21- 10-70  Provisions  shall  be  made  to  confirm  that  all  safety  critical  Space- 
craft/Tug and  Spacecraft/Orbiter  interfaces  are  securely  connected 
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Reason  for  deletion  - Redundant  with  requirement  No  2 

PTI-22-10-61  Redundant  fluid  or  electric  supply  lines  shall  not  be  located 
near  the  primary  line  containing  that  commodity 

Reason  for  deletion  - Mechanical  layout  requirement  only 

PTI-23-10-64  Capability  shall  be  provided  for  static  discharge  between  Tug 
and  Orbiter  and  between  the  Tug  and  Spacecraft 

Reason  for  deletion  - Electrical  system  design  requirement  only 

PTI-24- 10-64  The  return  of  current  to  the  power  source  shall  be  accomplished 
by  means  other  than  the  Tug  structure 

Reason  for  deletion  - Electrical  system  design  requirement  only 

PTI-25-10-64  Electrical  umbilical  disconnects  between  the  Orbiter  and  the  Tug 
and  between  the  Tug  and  Spacecraft  shall  be  separated  from  haz- 
ardous fluid  disconnects,  shall  be  qualified  as  explosion  proof, 
and  shall  not  have  power  applied  during  disconnect 

Reason  for  deletion  - Mechanical  design  requirement  only 

PTI-26-10-64  Power  circuits  shall  be  separated  from  critical  pyrotechnic  cir- 
cuits within  a cable  or  wire  bundle 

Reason  for  deletion  - Electrical  cable  layout  requirement  only 

PTI-27 -10-76  Spacecraft  should  be  grounded  to  Tug  structure  to  prevent  electro- 
static charge  buildup  and  an  electrical  shock  hazard  Within  the 
Spacecraft,  grounding  shall  be  such  as  to  preclude  an  electrical 
shock  A positive  ground  shall  exist  from  the  Spacecraft  to  the 
Orbiter  structure 

Reason  for  deletion  - Electrical  system  design  requirement  only 

PTI-28-10-77  Provision  shall  be  included  for  Spacecraft  caution  and  warning 
functions  which  will  provide  both  audible  and  visual  warning  to 
Orbiter  crew  of  hazardous  situations  while  the  Spacecraft  is  a- 
board  the  Orbiter  or  being  deployed 

Reason  for  deletion  - Requirement  is  redundant  with  No  20 

PTI-29-10-78  Sequence  logic  and  pyrotechnic  firing  circuits  of  the  Spacecraft 
shall  be  capable  of  sustaining  a failure  without  causing  a hazard 
to  the  flight  crew  or  damage  to  the  Orbiter,  Tug  or  other  Space- 
craft Spacecraft  pyrotechnic  logic  circuits  shall  receive  power 
from  a source  other  than  the  pyrotechnic  batteries 

Reason  for  deletion  - Electrical  system  design  requirement  only 

PTI-31-10-78  Pyrotechnic  initiation  circuits  shall  be  routed  separately  from 
power  circuits 
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Reason  for  deletion  - Electrical  layout  requirement  only 

PTI-40-10-74  No  single  operation  shall  result  in  flow  of  propellant  through 
the  Spacecraft  propulsion  system  The  APS  shall  be  inhibited 

while  in  the  Orbiter  payload  bay 

Reason  for  deletion  - Implicit  in  requirement  No  36 

PT I - 4 1 - 10 - 74  Spacecraft  sequencing  control  for  attitude  hold  and  main  engine 
starting  sequence  shall  be  remotely  code  commanded  by  the  Orbiter 
crew  or  ground  control.  Interlocks  shall  be  provided  to  prevent 
inadvertent  operations  of  the  Spacecraft  while  in  the  Orbiter 
payload  bay  or  during  the  deployment  phase  of  operation 

Reason  for  deletion  - Redundant  to  requirement  No  36 

PTI-42- 10-71  Spacecraft  operations  and  energy  levels  shall  be  minimized  while 
aboard  or  near  (TBD)  the  Orbiter. 

Reason  for  deletion  - System  design  goal  only 

PTI-43- 10-71  Provision  shall  be  made  for  verifying  critical  Spacecraft  systems 
readiness  before  activation. 

Reason  for  deletion  - Redundant  to  requirement  No  3 
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3 0 TUG/GROUND  INTERFACE  REQUIREMENTS  DELETED 

The  following  nine  baseline  requirements  were  among  those  listed  early  in  the 
study  for  assessment,  as  having  potential  impact  on  the  Tug/Ground  interface 
design  from  an  Orbital  Operations  standpoint  The  nine  presented  here  were 
assessed  and  found  to  be  operationally  duplicates  or  having  no  impact  on  Orbital 
Oerations  functions  They  have  been  deleted  from  further  consideration  by  this 
study  Reasons  for  deletion  accompany  each  requirement  statement. 

TGI-7- 10-58  The  planned  attitudes  of  the  Tug  during  release  and  separation 
from  the  Orbiter  shall  be  such  that  the  attitude  control  engines 
at  no  time  accelerates  the  vehicle  towards  the  Orbiter 

Reason  for  deletion  - This  requirement  is  first  placed  on  mission  planning  then 
executed  by  the  Tug  GN&C  System 

TGI-8-10-58  Tug  attitude  control  or  Tug  mam  engine  thrust  shall  not  be  used 
for  initial  separation  of  the  Tug  to  a safe  distance  (TBD)  from 
the  Orbiter 

Reason  for  deletion  - This  requirement  is  met  by  the  Orbiter  moving  away  from 
the  Tug 

TGI-26- 10-45  Mission  critical  single  failure  points  will  be  minimized  to  the 
maximum  extent  possible 

Reason  for  deletion  - This  is  a design  goal  only 

TGI-27-10-45  Alternate  or  redundant  means  of  performing  a critical  function 
shall  be  physically  separated  or  protected  such  that  an  event 
which  causes  the  loss  of  one  means  of  performing  the  function 
will  not  result  in  the  loss  of  alternate  or  redundant  means 

Reason  for  deletion  - Mechanical  layout  design  requirement  only 

TGI-28-10-46  Isolation  of  anomalies  of  mission  and  crew  essential  functions 
will  be  provided  to  assure  a failure  will  not  propagate  across 
any  interface 

Reason  for  deletion  - System  design  requirement  only 

TGI-29-10-51  The  proper  functioning  of  the  interface  between  the  STS  and  Tug 
shall  be  maintained  under  all  nominal,  contingency,  and  emergency 
operations  of  either  the  STS  or  the  Tug 

Reason  for  deletion  - Requirement  on  the  Orbiter/Tug  interface 

TGI- 30 - 10 -51  No  single  Tug  failure  shall  result  in  a hazard  which  jeopardizes 
the  flight  or  ground  crews  of  the  Shuttle,  general  public,  public/ 
private  property  and  the  ecology 

Reason  for  deletion  - Contained  within  the  scope  of  requirement  No  33 

TGI— 31- 10-54  As  a minimum,  Tug  shall  be  designed  to  sustain  a failure  and  re- 
tain the  capability  to  successfully  terminate  the  Tug  functions 
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without  injuring  flight  personnel  or  damaging  the  Orbiter  or 
other  payloads  (fail-safe) 

Reason  for  deletion  - Tug  internal  design  requirement 

TGI-32-10-54  Tug  operations  and  energy  levels  shall  be  held  to  a minimum  whi 
aboard  or  in  the  near  vicinity  of  the  Orbiter 


Reason  for  deletion  - System  design  goal  only 


4 0 TUG  SYSTEMS  REQUIREMENTS  .DELETED 

The  following  twelve  baseline  requirements  were  among  those  listed  early  in  this 
study  for  assessment,  as  having  potential  impact  on  the  Tug  Systems  design  from 
an  Orbital  Operations  standpoint  The  twelve  presented  here  were  assessed  and 
found  to  be  operationally  duplicates  or  having  no  impact  on  Orbital  Operations 
functions  They  have  been  deleted  from  further  consideration  by  this  study 
Reasons  for  deletion  accompany  each  requirement  statement 

TS-26- 10-58  Tug  shall  be  switched  from  command  control  to  internal  attitude 

control  after  Orbiter  has  been  sufficiently  moved  (TBD)  so  that 
no  Tug  attitude  change  could  result  in  collision  with  the  Orbiter 

Reason  for  deletion  - This  requirement  is  operationally  similar  to  requirement 
No  25 

TS-30-10-46  Isolation  of  anomalies  of  mission  and  crew  essential  functions 
will  be  provided  to  assure  a failure  will  not  propagate  across 
any  interface 

Reason  for  deletion  - System  design  goal  only 

TS-39-10-28  The  Tug  shall  not  initiate  its  propulsion  system  until  a safe 
separation  distance  and  attitude  relationship  between  Orbiter 
and  Tug  is  achieved.  The  Tug  propulsion  system  shall  not  cause 
impingement  of  exhaust  gases  that  would  be  harmful  to  the  Orbiter 

Reason  for  deletion  - This  requirement  is  operationally  similar  to  requirement 
No  25 

TS-41- 10-65  Electrical  wiring  must  not  be  routed  against  or  around  sharp  edges 

Reason  for  deletion  - Electrical  wiring  layout  requirement  only 

TS-42-10-65  Electrical  wiring  must  not  be  in  contact  with  flammable  fluids 

Reason  for  deletion  - Electrical  wiring  layout  requirement  only 

TS-43- 10-65  Electrical  circuits  which  will  be  cut  by  guillotine  cutters  must 
be  deadfaced 

Reason  for  deletion  - Electrical  system  requirement  only. 

TS-45-10-75  Spacecraft  critical  command  and  control  circuitry  shall  be  de- 
signed to  be  fail -operational /fail -safe  as  a minimum 

Reason  for  deletion  - This  is  a Spacecraft  requirement  only 

TS-46-10-66  Sequence  logic  and  pyrotechnic  firing  circuits  shall  be  at  least 
dual  redundant 

Reason  for  deletion  - There  are  no  pyrotechnics  planned  for  Tug 

TS-47- 10-66  Pyrotechnic  logic  circuits  shall  receive  power  from  a source 
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other  than  the  pyrotechnic  initiation  source 

Reason  for  deletion  - There  are  no  pyrotechnics  planned  for  Tug 

TS-48-10-66  Pyrotechnic  firing  circuits  shall  be  protected  from  electro- 
static charge  buildup 

Reason  for  deletion  - There  are  no  pyrotechnics  planned  for  Tug 

TS-49-10-66  Sequence  logic  and  pyrotechnic  firing  circuits  shall  be  capable 
of  sustaining  a failure  without  causing  a hazard  to  the  flight 
crew  or  damage  to  the  Orbiter  or  other  payloads 

Reason  for  deletion  - There  are  no  pyrotechnics  planned  for  Tug 

TS-50-10-66  To  insure  firing  of  safety  critical  pyrotechnic  devices  m parallel, 
the  design  of  pyrotechnic  circuits  must  prevent  constant  power 
drain  in  the  event  the  device  short  circuits  upon  activation 

Reason  for  deletion  - There  are  no  pyrotechnics  planned  for  Tug 
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APPENDIX 


SPACE  SHUTTLE  C&W  DEFINITION  AS  RELATED  TO  SPACE  TUG 
Purpose 

The  purpose  of  this  definition  is  to  clear  the  confusion  that  exists  every 
time  the  C&W  system  is  addressed  In  the  effort  of  putting  this  together 
it  became  apparent  there  is  not  a firm  definition  This  will  therefore 
indicate  what  appears  to  be  the  present  design  and  identify  issues  known 
to  be  uncertain 

Scope 

This  definition  will  be  largely  the  Space  Shuttle  defining  its  C&W  sys- 
tem, because  the  payload  is  merely  a user.  It  will  show  how  this  system 
relates  to  the  TUG  C&W  requirements.  Actual  numbers  of  C&W  parameters 
(Orbiter  System  or  TUG  System)  are  of  course  estimates  and  presently 
even  the  capability  is  uncertain 

1 0 ANOMALY  CATEGORIZATION 

Vehicle  and  subsystem  anomalies  that  require  flight  crew  attention  are 
classed  in  the  following  categories 

Emergency  - condition  creates  immediate  crew  hazard  {e  g fire 
or  rapid  depressurization) 

Caution  and  Warning  - actual  or  impending  anomalous  condition 

of  subsystem  element  (e.g  Hr,  pressure  or  Og  pressure) 
(Defined  Tug  Anomalies  Fall  Here) 

Advisory  - affects  parameters  other  than  the  critical  parameters 
(eg  loss  of  redundant  element) 
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2 0 C&W  SYSTEM  REQUIREMENTS 


MONITOR  VEHICLE  SUBSYSTEMS  FOR  MALFUNCTIONS 

ALERT  CREW  TO  EXISTENCE  OF  MALFUNCTIONS  WITH 
VISUAL  AND  AURAL  ALARMS 

PROVIDE  INFORMATION  AS  TO  MALFUNCTION  NATURE,  LOCATION  AND  CRITIC- 
ALITY 

ANNUNCIATORS  WILL 

SEPARATE  BETWEEN  VARIOUS  PRIORITY  ANNUNCIATIONS,  BE 
CENTRALLY  LOCATED  AND 
DUAL  REDUNDANT 

GENERATE  MASTER  ALARM  COINCIDENT  WITH  C&W  ANNUNCIATION 

PROVIDE  SIGNAL  FILTERING  & DELAY  PROVISIONS  TO  PREVENT  TRIGGERING 
ON  SHORT  TRANSIENTS  & NOISE 

RETAIN  ID  OF  SIGNALS  TRIGGERING  ALARM 

PROVIDE  MODE  WHEREBY  ANNUNCIATORS  ARE  INHIBITED  (ACKNOWLEDGE  MODE), 
ILLUMINATES  WHEN  MASTER  ALARM  SWITCH  DEPRESSED 

PROVIDE  SPECIFIC  INPUT  INHIBIT 

TRIGGERING  ON  ONE  INPUT  SHALL  NOT  PREVENT  TRIGGERING  FROM  ANOTHER 
INPUT 

AURAL  ALARM  VOLUME  PREFLIGHT  ADJUSTABLE 

NO  SINGLE  C&W  ELECTRONICS  FAILURE  SHALL  AFFECT  RESPONSE  TO  MORE  THAN 
ONE  INPUT 

SHALL  BE  DIGITAL  PROCESSOR  WITH  CAPABILITY  FOR  IN-VEHICLE  C/W  LIMIT 
CHANGES  ON  THE  GROUND  & IN  FLIGHT 
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3 0 CATEGORY  MECHANIZATION  SUMMARY 


EMERGENCY  CONDITIONS 

INDEPENDENT,  REDUNDANT  SYSTEMS  EMPLOYING  DEDICATED 
SENSORS,  DETECTORS,  VISIBLE/AUDIBLE  ALARMS 

CAUTION  & WARNING  CONDITIONS 

PRIMARILY  BY  DEDICATED  HARDWARE  C&W  SUBSYSTEM 
SECONDARILY  BY  BACK  UP  C&W  SOFTWARE  PERFORMANCE  MONITOR 
FUNCTION 

PRIMARY  & BACKUP  C&W  EMPLOY. 

OPERATIONAL  SENSORS 

VISIBLE/AUDIBLE  ALARMS 

FAULT  IDENTIFICATION  (C&W  STATUS  PANEL) 

INHIBIT  STATUS  DISPLAY 

ADVISORY  CONDITIONS 

DETECTED  BY  C&W  SOFTWARE  PERFORMANCE  MONITOR 
UTILIZES 

OPERATIONAL  SENSORS 

VISIBLE  ALARM  (SM  ADVISORY  LITE) 

OPTIONAL  AUDIBLE  ALARM 

CRT  FOR  FAULT  IDENTIFICATION  & INHIBIT  STATUS 
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4 0 ORBITER  C&W  SYSTEM 


The  system  is  pictured  in  Figure  1 
4 1 SYSTEM  ANOMALY  INPUT  CAPABILITY 
4 1 1 EMERGENCY  CONDITIONS 

Two  types  identified.  Maximum  capability  unknown  Some  require 
special  lites,  some  use  C&W  annunciation 

4 1 2 ORBITER  SYSTEM  STATUS 

120  FUNCTIONAL  INPUTS,  MIX  OF  ANALOG  AND  DISCRETE  TYPES 
FED  IN  PARALLEL  TO  BACKUP  C&W  PERFORMANCE  MONITOR 

4 1 3 BACKUP  C&W 

PERFORMANCE  MONITOR  (SOFTWARE  DERIVED}  FROM  SAME  120  FUNCTIONS 
ABOVE 

ACTIVATES  1 OF  THE  40  CWA  LIGHTS 

SETS  MASTER  ALARM,  CAUTION  & WARNING  TONES 

MANUAL  RESET  REQUIRED 

4 2 SYSTEM  OUTPUT  CAPABILITY 

4 2.1  AURAL  ALARMS  (ALL  DUAL  REDUNDANT) 

SIREN 

ACTIVATES  SIREN  OUTPUT  AND  RESET  WHEN  SIREN  INPUT  IS  REMOVED 


KLAXON 

ACTIVATES  KLAXON  OUTPUT  AND  RESET  WHEN  KLAXON  INPUT  IS  REMOVED 


BACKUP  C&W 

ACTIVATES  WITH  BACKUP  C&W  (PERFORMANCE  MONITOR)  OUTPUT  AND 
RESET  WHEN  BACKUP  C&W  OUTPUT  IS  REMOVED 
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Figure  1 Orbiter  C&W  System 


VISUAL  ALARMS 


$M  ADVISORY 

ACTIVATES  THE  SM  ADVISORY  TONE  (550  Hz)  AND  RESET  WHEN  SM 
IS  REMOVED 

422  VISUAL  ALARMS 


MASTER  ALARM  LITES  DUAL  REDUNDANT 
C&W  ANNUNCIATORS 

39  PARALLEL  SYSTEM  OUTPUTS  TO  THE  CWA 
1 BU  C&W  OUTPUT  TO  THE  CWA 

C&W  STATUS  PANEL 

120  CODED  OUTPUTS  FOR  DISPLAY  ON  THE  CWS 
423  MI SC  OUTPUTS 


MAINTENANCE  RECORDER 

START  COMMAND  TO  THE  MAINTENANCE  RECORDER  COINCIDENT  WITH 
MASTER  ALARM  ACTIVATION 

TM  OUTPUT 

SIGNAL  TO  THE  TELEMETRY  SYSTEM  COINCIDENT  WITH  MASTER  ALARM 
ACTIVATION  REMAINS  ON  UNTIL  MASTER  ALARM  IS  RESET 

4 3 SYSTEM  PANEL  CONTROLS 


CHANNEL  SELECT 

THUMBWHEEL  SWITCH  WITH  BCD  OUTPUT  SELECTS  ONE  OF  THE  120 
INPUT  CHANNELS 

UPPER/LOWER  LIMIT 

TOGGLE  SWITCH 

SELECTS  THE  UPPER  OR  LOWER  LIMIT  TO  BE  CHANGED  OR  READ 
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LIMIT  VALUE  SELECT 


THUMBWHEEL  SWITCH  WITH  BCD  OUTPUT  SELECTS  NEW  LIMIT  VALUE 
LIMIT  SET 

MOMENTARY  TOGGLE  SWITCH 

ENTERS  THE  NEW  LIMIT  VALUE  FOR  THE  SELECTED  INPUT 

CHANNEL  INHIBIT  ON/OFF 

MOMENTARY  TOGGLE  SWITCH 

INHIBITS  THE  CHANNEL  SELECT  THUMBWHEEL  (ON) 

REMOVES  INHIBIT  ON  THE  SELECTED  CHANNEL  (OFF) 

LIMIT  READ 

MOMENTARY  TOGGLE  SWITCH 

COMMENTS  READOUT  OF  ACTIVE  LIMIT  VALUE  FOR  SELECTED  INPUT 
MEMORY  READ  A (FORE) 

DISPLAYS  ALL  C&W  ANNUNCIATIONS  SINCE  LAST  MEMORY  CLEAR  COMMAND 
ON  FWD  ANNUNCIATOR  PANEL  (CUA) 

MEMORY  READ  B (AFT) 

DISPLAYS  ALL  OUT-OF-LIMIT  INPUTS  SINCE  LAST  MEMORY  CLEAR  COMMAND 
ON  AFT  STATUS  PANEL  (CWS) 

MEMORY  CLEAR 

CLEARS  STORED  IDENTIFICATION  OF  OUT-OF-LIMIT  INPUTS 
TRIP  STATUS 

PROVIDES  REAL-TIME  READOUT  OF  OUT-OF-LIMIT  INPUTS  ON  THE  CWS 
INHIBIT  STATUS 

IDENTITIES  INPUTS  THAT  ARE  INHIBITED  ON  THE  CWS 
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4 4 CREW  INTERACTION  WITH  PERFORMANCE  MONITOR  FUNCTION 


TEST  LIMITS  FOR  BACKUP  C&W  ALTERABLE  WITH  CRT/KYBD 
DETAILS  OF  ANOMALY  AVAILABLE  WITH  CRT/KYBD 

4 5 BACKUP  C&W  AND  SM  ADVISORY  RELATIONSHIP 


BACKUP  C&W  - PERFORMANCE  MONITORING  SOFTWARE 

SAME  PARAMETERS  AS  HARDWARE  C&W 
SAME  LIMITS  AS  HARDWARE  C&W 
UTILIZES  C&W  ELECTRONICS  FOR 
AUDIBLE  - TONE 
VISUAL  - LIGHTS 

SEPARATE  PATH  IN  C&W  ELECTRONICS 

SM  ADVISORY  - SOFTWARE 

LOWER  LEVEL  PARAMETERS 
UTILIZES  C&W  ELECTRONICS  FOR 
AUDIBLE  - TONE 
RESET  VIA  KEYBOARD 
LATCH/UNLATCH  - IN  SOFTWARE 
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4 6 C&W  ELECTRONICS  REDUNDANCY  SUMMARY 


CEI  REQUIREMENT  STATES  THAT  "NO  SINGLE  C&W  ELECTRONICS  FAILURE  SHALL 
AFFECT  RESPONSE  TO  MORE  THAN  ONE  INPUT  " 

C&W  ELECTRONICS  MULTIPLEXES  120  INPUTS,  PERFORMS  ANALOG  COMPARISON  VIA 
SINGLE  COMPARATOR  & LOGICALLY  OPERATES  ON  SINGLE  SERIAL  DATA  STREAM 

SOFTWARE  BACKUP  C&W  PROVIDES  REDUNDANCY  BY  INDEPENDENTLY  MONITORING 
SAME  PARAMETERS  AS  C&W  ELECTRONICS  AND  DRIVES  SEPARATE  ANNUNCIATOR  NO  40 

C&W  ELECTRONICS  FUNCTIONS  REQUIRED  FOR  SOFTWARE  BACKUP  ARE  REDUNDANT 
MASTER  ALARM  AND  TONE  GENERATOR 

See  Figure  2 C&W  System  Redundancy  Implementation 
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Figure  2 C&W  System  Redundancy  Implementation 


4 7 ORBITER  101  C&W  INPUTS  & ANNUNCIATORS 


ORBITER  SYSTEM  STATUS  TO  C&W 

ANNUNCIATORS 

ORBITER  SYSTEM  STATUS  TO  C&W 

ANNUNCIATORS 

H2  TANK  ASSY  1 PRESSURE 

H2  PRESSURE 

MAIN  BUS  A UNDERVOLT 

MN  A 

H2  TANK  ASSY  2 PRESSURE 

MAIN  BUS  B UNDERVOLT 
MAIN  BUS  C UNDERVOLT 

MN  B 
MN  C 

02  TANK  ASSY  1 PRESSURE 

02  PRESSURE 

AC  BUS  1 OVERVOLT/UNDERVOLT 

AC  1 

09  TANK  ASSY  2 PRESSURE 

AC  BUS  2 OVERVOLT/UNDERVOLT 

AC  2 

AC  BUS  3 OVERVOLT/UNDERVOLT 

AC  3 

STACK  COOLANT  OUTLET  TEMP 

FUEL  CELL  1 

AC  BUS  1 OVERLOAD 

AC  1 0 LOAD 

02  REACTANT  VALVE-CLOSED 

h2  reactant  valve-closed 

AC  BUS  2 OVERLOAD 

AC  2 0 LOAD 

AC  BUS  3 OVERLOAD 

AC  3 0 LOAD 

COOLANT  PUMP  STATUS 
STACK  COOLANT  OUTLET  TEMP 

FUEL  CELL  2 

FCS  FAILURE  A 
FCS  FAILURE  B 

FCS 

02  REACTANT  VALVE-CLOSED 
H2  REACTANT  VALVE-CLOSED 

C&W  ELECTRONICS  FAILURE 

C&W  FAIL 

COOLANT  PUMP  STATUS 
STACK  COOLANT  OUTLET  TEMP 

FUEL  CELL  3 

PMS  ALARM  A 
PMS  ALARM  B 

BACKUP  C&W 

02  REACTANT  VALVE-CLOSED 
H2  REACTANT  VALVE-CLOSED 
COOLANT  PUMP  STATUS 

GPC  1 FAILURE 
GPC  2 FAILURE 
GPC  3 FAILURE 
GPC  4 FAILURE 

COMPUTER 

HYD  SYS  1 SUPPLY  PRESSURE 
HYD  SYS  2 SUPPLY  PRESSURE 

HYD  PRESSURE 

GPC  5 FAILURE 

HYD  SYS  3 SUPPLY  PRESSURE 
HYD  SYS  1 RESERVOIR  LEVEL 

HYD  QUANTITY 

G&N  FAILURE  A 
G&N  FAILURE  B 

GNC 

LOW 

FLIGHT  CONTROL  SYS  SATUR- 

CONTROL 

HYD  SYS  2 RESERVOIR  LEVEL 
LOW 

HYD  SYS  3 RESERVOIR  LEVEL 

AT ION  A 

FLIGHT  CONTROL  SYS  SATUR- 
ATION B 

SATURATION 

LOW 
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4 7 ORBITER  101  C&W  INPUTS  & ANNUNCIATORS  (CONTINUED! 


ORBITER 

SYSTEM  STATUS  TO  C&W 

ANNUNCIATORS 

APU  1 

TURBINE  EXHAUST  OVER- 

APU 1 

TEMP 

APU  2 

TURBINE  EXHAUST  OVER- 

APU 2 

TEMP 

APU  3 

TURBINE  EXHAUST  OVER- 

APU 3 

TEMP 

CABIN 

AIR  FLOW  RATE 

AIRFLOW 

CABIN 

PRESSURE 

CABIN  PRESSURE 
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5 0 ORBITER/PAYLOAD  C&W  SYSTEM  ACCOMMODATIONS  AND  INTERPLAY 


As  shown  in  Figure  3,  50  C&W  data  channels  (analog  and/or  discrete) 
from  the  payload  interface  input  to  a comparator  in  the  payload  C&W  elec- 
tronics unit  Upon  detection  of  an  out-of-tolerance  condition  in  one  of 
the  50  inputs,  the  payload  C&W  electronics  will  active  an  individual  light 
in  the  payload  status  board  and  the  appropriate  annunciator  module  in  the 
payload  C&W  Annunciator  Matrix  The  payload  C&W  electronics  also  provides 
outputs  for  starting  the  maintenance  recorder  and  master  alarm  Up  to 
TBD  comparator  outputs  can  be  OR'd  (pre-mission)  to  activate  a single 
annunciator  of  the  25  available  m the  payload  C&W  annunciator  matrix 
As  shown  in  Figure  3,  one  annunciator  is  dedicated  to  the  backup  C&W, 
Performance  Monitoring  Derived  Function.  The  25  outputs  of  the  combination 
logic  OR-gates  can  be  OR'd  (pre-mission)  in  any  desired  combinations  to 
activate  up  to  5 lights  reserved  m the  payload  C&W  annunciator  panel 
The  five  (5)  payload  outputs  may  be  OR'd  to  a single  "payload"  annunciator 
reserved  m the  orbiter  C&W  matrix  The  payload  C&W  matrix  will  be  used 
to  identify  which  payload  as  well  as  system/parameter  is  out  of  tolerance 

NOTE  There  is  a current  effort  to  combine  the  Orbiter  C&W  Electronics 
Unit  and  the  Payload  C&W  Electronics  Unit  The  Input/Output  capability 
is  therefore  uncertain  at  this  time 
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Note  C&W  electronics  units  may  be  combined,  with  I/O  capabilit; 
Figure  3 Payload  Accommodations  C&W  Data  Flow  Diagram 
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6 0 CAUTION  AND  WARNING  IMPLEMENTATION  FOR  THE  TUG  PAYLOAD 

Each  C&W  parameter  is  monitored  by  two  independent  transducers  and  sub- 
sequent data  paths  Figure  4 illustrates  the  C&W  interfaces 

6 1 PRIMARY  C&W  PATH 


One  transducer  is  hardwired  to  the  C&W  electronics  where  it  is  monitored 
and  limit  checked  against  preprogrammed  limits  If  the  parameter  exceeds 
its  preset  limits  then  an  alarm  is  sounded  and  a titled  indicator  light 
corresponding  to  the  affected  parameter  is  illuminated  on  the  C&W  panels 
at  the  crew  stations  Any  payload  C&W  indicator  that  is  activated  on  the 
AFT  station  panels  will  result  in  the  payload  C&W  light  being  illuminated 
on  the  forward  crew  station  C&W  panels  This  “hardwired"  path  through  the 
C&W  electronics  constitutes  the  primary  C&W  path 

6.2  SECONDARY  C&W  PATH 

The  second  transducer  is  accessed  either  by  the  Tug  data  management 
system  (DMS)  and  output  to  the  orbiter  PDI  or  is  output  directly  across 
the  interface  into  the  MDM's  dedicated  to  payload  support  This  parameter 
is  accessed  by  the  GPC  performance  monitor  function  where  it  is  limit 
checked  against  preprogrammed  C&W  limits  An  out-of-limit  condition  de- 
tected by  this  function  will  cause  the  GPC  to  illuminate  the  backup  C&W 
indication  at  the  FORWARD  and  AFT  stations.  The  payload  light  will  also 
be  illuminated  at  the  forward  station 

6 3 SYSTEM  OPERATION 

During  nominal  operation  of  the  C&W  system  both  the  titled  indicator 
from  the  primary  path  and  the  backup  indicator  from  the  GPC  system  will  be 
illuminated  Illumination  of  either  singly  is  grounds  for  suspicion  of  a 

C&W  problem  If  only  the  C&W  backup  indicator  is  illuminated  then  the  crew 

must  call  up  a display  of  C&W  parameters  to  determine  the  cause  of  the 
C&W  condition  This  call  up  and  display  will  be  accomplished  via  the  dis- 
play and  keyboard  located  at  either  station 
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6 3 1 TEST  LIMIT  CHANGING 


The  tolerance  test  limits  for  the  primary  C&W  path  (through  C&W  electronics) 
are  inflight  alterable  by  a series  of  switches  at  the  C&W  panels 

The  GPC  test  limits  for  the  backup  path  are  inflight  alterable  through 
the  display/ keyboards 

632  OPERATION  VIA  RF  LINK 

Following  the  deployment  of  the  Tug  vehicle,  the  C&W  function  remains  ac- 
tive until  the  Tug  is  a safe  distance  from  the  Orbiter  During  this  period 
the  data  and  command  signals  are  transmitted  between  the  Tug  and  Orbiter 
via  an  S-Band  relay  system  The  data  from  the  Tug  is  acquired  through  the 
payload  interrogator  and  payload  signal  processor  components  and  is  output 
to  the  interleaver  in  a 16  kbps  serial  data  stream  Commands  from  the 
Orbiter  to  the  Tug  are  output  from  the  GPC  system  payload  MDM's  to  the 
payload  signal  processor  The  signal  processor  then  outputs  this  data  to 
the  payload  interrogator  for  transmission  to  the  Tug  This  is  illustrated 
in  the  lower  portion  of  Figure  4 

The  hardwired  redundant  C&W  system  is  no  longer  available  once  the  Tug 
umbilical s are  disconnected  The  C&W  system  then  becomes  simplex  and 
relies  on  the  RF  relay  link  rather  than  hard  wires 
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6 4 TUG  SYSTEM  C&W  INPUTS  & ANNUNCIATORS 


TUG  SYSTEM  STATUS  TO  C&W 

LH2  TANK  PRESSURE 
L02  TANK  PRESSURE 

N2H4  TANK  TEMP  1 

N2H4  TANK  TEMP  2 

N2H4  TANK  TEMP  3 
FUEL  CELL  L02  PRESSURE 
FUEL  CELL  LH2  PRESSURE 
DEPL  ADAPT  ARMED 
APS  ARMED 

TUG  MAIN  PROPL  ARMED 
AUX  BATTERY  TEMP 
SPACECRAFT  DEPL  ARM  SAFE 
He  BOTTLE  PRESS  1 
H£  BOTTLE  PRESS  2 
He  BOTTLE  PRESS  3 
UMB  PANEL  DISENGAGED 


ANNUNCIATORS 

LH2  TANK  PRESSURE 
L02  TANK  PRESSURE 

N2H4  TANK  TEMP 

FUEL  CELL  L02  PRESSURE 
FUEL  CELL  LH2  PRESSURE 
DEPL  ADAPT  ARMED 
APS  ARMED 

TUG  MAIN  PROPL  ARMED 
AUX  BATTERY  TEMP 
SPACECRAFT  DEPL  ARM  SAFE 
He  BOTTLE  PRESSURE 

UMB  PANEL  DISENGAGED 
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Four  symbols  are  used  to  form  the  bars  of  the  bar  chart  Symbol  o is 
used  to  designate  those  functions  which  are  in  the  critical  path  For 
example,  the  first  critical  path  is  derived  for  the  XUS  and  consists  of 
the  following  functions  Contract  Software  Development,  Plan  Ground 
Software  Development,  EDD-Executive/Tracking/Planmng,  Proqram  Ground 
Track/Plan/Executive  Software,  Verify  Executi ve/Track/P lanmng  Software, 

IUS  Mission  planning  and  Optimization,  It'S  Abort  planning,  I US 
Mission  Specific  EDD,  IUS  Mission  Specific  Program,  IUS  Mission  Program 
Verification,  IUS  Mission  Simulation  Training,  Conduct  IUS  mission 
Operations,  and  IUS  Post-mission  Peports  None  of  those  events  can  exceed 
its  allocated  time  without  slipping  the  program  launch  date  The  symbol 
e is  used  to  designate  the  span  of  time  beginning  at  the  earliest  time  all 
constraints  are  met  for  a particular  activity  to  begin.  The  symbol  L is 
utilized  to  indicate  the  span  of  time  from  the  latest  possible  time  an 
activity  can  begin  through  its  completion.  Each  symbol  designates  one 
week  of  activity.  If  an  activity  is  not  in  the  most  critical  path  it 
will  contain  the  symbol  E and  the  symbol  L and  either  the  symbol  0 or  +. 

In  that  context,  the  symbol  0 indicates  the  overlap  between  bars 
representing  an  early  start  and  a late  start  For  example  the  task  "Analyze 
Tug  Component  Characteristics"  requires  seven  weeks  to  accomplish.  The 
earliest  it  can  begin  is  February  1983  There  are  six  consecutive  E symbols 
followed  by  a single  0 symbol  followed  by  six  consecutive  L symbols  The 
0 symbol  is  to  be  interpreted  as  a week  shared  between  the  s and  L activity 
periods 

The  + sign  indicates  program  "slack”,  that  is,  the  activity  is  not  critical 
and  may  be  accomplished  at  any  time  between  the  first  e and  the  last  L 

Figure  10  5 0-2  is  a planning  tool  The  next  step  in  overall  planning  is 
to  select  the  optimal  calendar  time  for  the  accomplishment  of  each  task, 
where  the  time  is  at  the  option  of  the  planner.  This  eliminates  the 
critical  path  from  consideration  but  does  allow  the  planner  to  choose 
the  calendar  period  of  accomplishment  of  the  non-cntical  activities 

One  tool  which  aids  in  the  selection  of  the  optimum  time  is  the  requirement 
for  allocation  of  resources  to  accomplish  the  tasks  which  are  illustrated 
in  the  PERT  network  and  the  bar  chart  This  is  an  interactive  and  iterative 
process  and,  therefore,  only  the  first  modification  is  illustrated.  The 
PERT  chart  as  it  was  initially  formulated  requires  that  a duration,  or 
tiaie  of  accomplishment  be  estimated  The  durations  entered  in  the  initial 
factors,  one  of  which  is  the  level  and  skill  of  manpower  to  be  applied  to 
the  accomplishment  of  the  task  Table  10  5 0-1  presents  the  input  informa- 
tion required  to  estimate  the  kind,  type,  and  schedule  of  manpower  require- 
ments against  the  PERT  network  The  mnety-six  activities  of  the  program  are 
listed  vertically,  the  horizontal  axis  defines  the  type  of  manpower  to 
be  applied  to  the  activity  and  the  matrix  cell  defined  by  the  inter- 
section of  the  horizontal  and  the  vertical  is  the  point  at  which  the  number 
of  manhours  estimated  for  the  particular  skill  against  the  specific  job 
is  entered 
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